Schema validation rejects requests that do not match the declared types, sizes and fields of an API. It reduces malformed input, oversized payloads and some mass assignment. It does not stop attacks that use valid looking requests, such as reading another user's record by changing an ID.
What schema validation means
An API schema, often written in OpenAPI, describes each operation: the path, the allowed methods, parameters, request body fields and response shapes. Validation compares live traffic with that description. It can run in a gateway, in a framework middleware, or inside your handlers.
What it stops well
OWASP's REST guidance says not to trust incoming parameters or objects, and to validate length, range, format and type. A schema is a convenient place to write those rules once.
- Wrong types and formats. A string where a number belongs is rejected before it reaches business code.
- Oversized input. Maximum string lengths, array sizes and body limits help with OWASP API4. The cheat sheet recommends size limits and a 413 response for oversized payloads.
- Unexpected content types. The cheat sheet says to reject unsupported content types with 415.
- Unknown fields. If your schema forbids extra properties, a client cannot slip an
isAdminfield into a request body. This helps against mass assignment, which OWASP API3 describes as client input mapped directly onto internal properties.
What it does not stop
| Attack | Why a schema does not help |
|---|---|
| Changing an object ID to another user's | The request is valid in shape |
| Calling an admin function as a normal user | The request is valid in shape |
| Brute forcing a login | Each request is individually valid |
| Abusing a business flow | Each step is valid, the pattern is not |
| Flaws in the logic after validation | Validation passes, then the bug runs |
OWASP's prevention advice for API3 also suggests enforcing a schema on responses, so the API returns only the properties it should. That covers data exposure from the other direction.
A practical setup
- Keep one schema as the source of truth and generate or check validation from it.
- Set explicit maximums for strings, arrays and bodies, not only types.
- Forbid unknown properties on write operations.
- Validate responses in tests, so a new field cannot leak by accident.
- Log validation failures. The REST cheat sheet notes that high failure volumes suggest abuse.
- Pair the schema with real authorization tests.
Try it yourself
Click through it at your own pace, or open it full screen. Look for findings that a type check would not have caught.
Quick check
Is schema validation the same as input sanitisation?
No. Validation decides whether input is acceptable. Sanitisation or output encoding handles how data is used later, for example in a query or a page. You usually need both.
Where should validation run, gateway or application?
Both are reasonable. A gateway gives early rejection and one place to configure. The application still needs its own checks, because it is the last line and understands business rules.
Safeguard's free scan at gold.safeguard.sh/scan covers dependency risk in the libraries your validation code relies on.
Sources
- OWASP REST Security Cheat Sheet
- OWASP API3:2023 Broken Object Property Level Authorization
- OWASP API4:2023 Unrestricted Resource Consumption
Last reviewed: 19 October 2026.
