validation

Overview

An API accepts data from the outside world on almost every route, and that data cannot be trusted. Input validation is the discipline of checking that incoming data matches what the API expects — the right type, format, range, and shape — before it is used. Missing or weak validation underlies many API vulnerabilities, from injection to mass assignment to resource exhaustion. This lesson covers validating API input defensively.

Learning objectives

• Explain why all API input must be treated as untrusted.
• Describe schema-based validation and the allowlist approach.
• Recognize mass assignment and how strict validation prevents it.
• Identify where validation belongs and why client-side checks are not enough.

Core concept

Input validation means verifying that data arriving in a request conforms to expectations before the application acts on it. APIs receive input from many places — path and query parameters, headers, and structured request bodies (usually JSON) — and every one of them is attacker-controllable. The safest approach is allowlist validation (also called positive validation): define exactly what is acceptable and reject everything else, rather than trying to blocklist known-bad values.

A closely related idea is schema validation: describe the expected structure of a request body (which fields exist, their types, whether they are required, and allowed ranges/lengths) and reject any request that does not conform. A schema turns validation into an explicit, enforceable contract.

How it works

Robust validation checks several dimensions of each input:

• Type — is it a string, number, boolean, array, or object as expected?
• Format — does it match the required pattern (email, date, UUID)?
• Range/length — is a number within bounds; is a string within a maximum length; is an array within a size limit?
• Presence — are required fields present, and are unexpected fields rejected?

That last point prevents mass assignment: if a handler blindly binds every field from the JSON body onto an internal object, a client could send an extra field the API never intended to expose — for example adding "role": "admin" or "isVerified": true to a profile-update request. With a strict schema that only accepts the fields a user may set, the extra field is rejected or ignored. Validation should happen server-side, because any client-side check can be bypassed by sending requests directly to the API. Well-designed APIs validate early, reject invalid input with a clear 400 Bad Request, and never rely on the client to sanitize.

Practical example

In an isolated lab, a PATCH /api/v1/users/me endpoint lets you update your own display name. The intended body is {"displayName": "..."}. Testing responsibly, you add an extra field: {"displayName": "test", "role": "admin"}. On a vulnerable implementation that binds all body fields onto the user record (mass assignment), the role is silently upgraded — a privilege escalation caused purely by missing validation. On a correctly built endpoint, the schema accepts only displayName; the unexpected role field is rejected or dropped and the request either fails with 400 or updates nothing extra. The fix is to validate the body against an explicit allowlist of user-settable fields, and to never derive privileged attributes from client input.

Cybersecurity relevance

Input validation is a foundational defense that cuts across many vulnerability classes. Proper validation and safe data handling reduce injection risks (though injection also requires parameterized queries and correct output handling), block mass assignment and privilege escalation, and — via size and rate limits — help prevent resource-exhaustion and denial-of-service. It is important to understand validation as defense in depth: validating input does not by itself stop SQL injection (that needs parameterized queries) or replace authorization checks, but it removes a large amount of attacker leverage and enforces the API's contract. Defenders implement server-side schema validation on every endpoint, use allowlists, set explicit limits, and return safe, non-revealing error messages. Testers probe for fields the API mishandles, missing bounds, and endpoints that accept unexpected input.

Common mistakes

• Trusting client-side validation and skipping server-side checks, which are trivially bypassed by calling the API directly.
• Blocklisting bad input instead of allowlisting acceptable input, leaving gaps for novel payloads and encodings.
• Binding all request fields onto internal objects (mass assignment) instead of accepting only an explicit set of allowed fields.
• Omitting size/length/range limits, enabling oversized payloads and resource exhaustion.
• Leaking internal details in validation error messages, aiding an attacker's mapping of the system.

Key takeaways

• All API input — parameters, headers, and bodies — is untrusted and must be validated server-side before use.
• Prefer allowlist and schema validation: define the exact acceptable structure, types, ranges, and fields, and reject everything else.
• Strict field allowlisting prevents mass assignment, where extra body fields (like role) would otherwise alter data the client should not control.
• Validation is defense in depth: it reduces injection, mass assignment, and resource-exhaustion risk but complements, not replaces, parameterized queries and authorization.

Check your understanding

• What is mass assignment, and how does allowlist-based schema validation prevent it?
• Why is server-side validation required even when the client application already validates input?