---
{
  "title": "Input validation",
  "summary": "Input validation checks that incoming values satisfy the application's expected structure and meaning.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Input Validation",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Input validation checks that incoming values satisfy the application's expected structure and meaning. A valid date may still be inappropriate for a booking that cannot occur in the past. Validate on trusted systems before downstream processing, including data received from partners and internal services.

## A practical example

A registration service checks the length and format of a display name, then separately verifies that a selected membership plan is available. The browser provides helpful feedback, but the server repeats the checks because callers can bypass the interface.

## What to check

List accepted types, ranges, lengths, encodings, and relationships between fields. Reject unexpected properties where appropriate and test boundary values, malformed input, and business-invalid combinations.

## A common pitfall

Filtering a few dangerous characters does not establish validity. Validation also does not replace parameterized queries or context-specific output encoding.

## Think it through

A discount percentage is numeric but exceeds the allowed maximum. Should a type check accept it?

**Answer:** No. Semantic validation must enforce the permitted business range before any price is calculated.

## Validate a value in its business setting

Suppose a fictional training centre accepts a room booking. A room number, starting time, duration, and attendee count each have a type. Their relationships matter too: the room must exist, its capacity must cover the group, and the requested period must fit an available slot. Individually well-formed fields can still describe an impossible or unauthorized booking.

Represent these requirements explicitly. Maximum string lengths and collection sizes prevent unexpected resource consumption. An enumerated booking status prevents arbitrary internal states. Cross-field checks stop an end time preceding the start time. Authorization decides whether the caller can reserve that room at all. Combining those concerns into a single vague 'clean input' function makes failures harder to explain.

Canonicalization also affects the decision. If different components interpret an encoded value differently, a validator may approve one meaning while a later component processes another. Prefer one documented parsing path and validate the resulting representation. Repeated decoding or ad hoc transformations across services can create disagreement rather than additional safety.

## Design useful failure cases

For the room-booking example, write a short table of acceptable and unacceptable requests: a normal booking, too many attendees, an unknown property, a missing duration, and a conflicting time. Include boundary values exactly at the permitted limit. Decide how the API communicates failure without exposing internal implementation details.

A good validation error tells a legitimate caller how to correct a request. It should not include credentials, a full database statement, or a stack trace. Recheck rules whenever the business process changes; a new booking category may need different capacity or approval requirements. Validation describes accepted data, while safe database calls and safe rendering still protect the interpreters that later consume it.

## Related concepts

- [[injection]]
- [[authorization]]