Overview
API input validation testing checks whether endpoints properly validate and safely handle input — including guarding against mass assignment. This lesson covers it.
Learning objectives
- Explain testing API input validation.
- Identify validation weaknesses (incl. mass assignment).
- Connect validation testing to injection and abuse.
Core concept
API validation testing checks whether endpoints properly validate their input (types, required fields, ranges, formats) and safely handle it — from the web-security API-validation module. Weaknesses to hunt for: inputs that reach unsafe operations (injection), improper type/format handling, acceptance of unexpected/extra fields (mass assignment — a client setting fields it shouldn't, like isAdmin), and missing server-side validation (since APIs are directly callable, client-side validation doesn't protect them). Testing (safely, in-scope) submits unexpected inputs and extra fields to see how the endpoint responds.
How it works
Using the schema and the researcher's test accounts, the researcher submits inputs that probe validation: wrong types, out-of-range values, missing/malformed fields, and extra fields the endpoint shouldn't accept (testing for mass assignment — e.g. adding a privileged field to see if it's bound). They also check whether inputs reaching queries/commands are safely handled (injection, tested per the injection modules). Because APIs are directly callable, the researcher tests the API directly (not via any client-side validation). Findings — mass assignment (extra fields accepted), injection via unvalidated input, or improper handling — are documented with reproduction (using test accounts) and fixes (schema validation, constrain accepted fields).
Practical example
Testing an in-scope API endpoint that updates a user profile, the researcher submits the expected fields plus an unexpected role field. The endpoint accepts and applies it — a mass-assignment flaw letting a client set a field (role) it shouldn't. They document it (reproduction with their test account, impact — potential privilege change) and a fix (validate against a schema; constrain accepted fields; ignore/reject unexpected ones). Testing the API directly with unexpected input revealed a validation flaw a UI-only view would miss.
Cybersecurity relevance
API validation weaknesses — mass assignment, injection via unvalidated input, improper handling — are recognized API risks (from the web-security API-validation module) and valuable bug bounty findings, especially since APIs are directly callable and often trusted by other systems. Mass assignment (binding unexpected fields) can lead to privilege changes or data tampering. Testing directly with unexpected inputs/extra fields (safely, with test accounts) finds these. For defenders, fixes are schema/allowlist validation, constraining accepted fields, and safe handling (parameterization, encoding). It complements authentication/authorization testing for comprehensive API coverage.
Common mistakes
- Not testing for mass assignment (submitting extra/unexpected fields).
- Relying on client-side validation rather than testing the API directly.
- Treating validation as sufficient for injection instead of also checking safe handling.
Key takeaways
- API validation testing checks proper input validation (types, fields, ranges) and safe handling, including guarding against mass assignment (accepting unexpected fields like
isAdmin). - Test the API directly (it's directly callable) with unexpected inputs and extra fields, using test accounts, safely and in-scope.
- Mass assignment, injection via unvalidated input, and improper handling are valuable findings; fixes are schema/allowlist validation, constraining accepted fields, and safe handling.
Check your understanding
- What is mass assignment, and how is it tested on an API?
- Why must API validation be tested directly rather than relying on client-side validation?