Overview
APIs must validate input just as rigorously as any other interface — arguably more, since they are directly callable and often trusted by other systems. This lesson covers input validation in the API context.
Learning objectives
- Apply input validation to API requests.
- Explain schema/type validation for structured data.
- Connect API validation to injection and abuse prevention.
Core concept
API input validation checks that request data (path/query parameters, headers, and the JSON body) conforms to expectations before use. For structured payloads, this often means schema validation — verifying types, required fields, formats, ranges, and rejecting unexpected fields. As always, prefer allowlist validation (accept known-good) over blocklists, validate server-side, and treat all API input as untrusted regardless of which client sent it.
How it works
Each API request's inputs are validated against a defined schema/expectation: correct types (number vs string), required vs optional fields, allowed value ranges, and formats. Requests that do not conform are rejected (typically 400). This reduces attack surface and catches malformed or malicious input early. As with all interfaces, validation is defense in depth, not a substitute for context-specific safe handling — parameterized queries still prevent injection, output encoding still prevents XSS, and object authorization still governs access. A subtle API concern is mass assignment: binding request fields directly to internal objects can let clients set fields they shouldn't (e.g. isAdmin), so validation should also constrain which fields are accepted.
Practical example
An endpoint expecting { "quantity": <integer 1–100>, "productId": <string> } validates the body against that schema: it rejects a non-integer quantity, an out-of-range value, a missing productId, or extra fields like isAdmin that a client might try to smuggle in (mass-assignment protection). Only conforming requests proceed, and even then values are used safely (parameterized queries, authorization checks). The schema both narrows input and blocks unexpected fields.
Cybersecurity relevance
Weak API input validation contributes to injection, mass assignment, and other abuses; strict schema/allowlist validation is standard API hardening and appears in API risk guidance. Because APIs are directly callable and often consumed by other trusted services, unvalidated input can propagate widely. Validation must be paired with safe handling (parameterization, encoding) and authorization — it reduces surface but does not by itself stop injection. Testers send malformed, out-of-range, and extra-field inputs; defenders validate against schemas server-side and constrain accepted fields.
Common mistakes
- Trusting API input because "our own client sends it" — APIs are directly callable and input is untrusted.
- Mass assignment — binding request fields directly to internal objects without constraining accepted fields.
- Treating validation as sufficient to prevent injection/XSS instead of pairing it with safe handling.
Key takeaways
- Validate all API input (params, headers, body) server-side against a schema — correct types, required fields, ranges, formats — preferring allowlists.
- Constrain which fields are accepted to prevent mass assignment (clients setting fields they shouldn't).
- Validation is defense in depth, reducing surface but not replacing parameterized queries, output encoding, and object authorization.
Check your understanding
- What is mass assignment, and how does constraining accepted fields prevent it?
- Why is API input validation necessary even when only your own official client is expected to call the API?