Overview
Input validation is the practice of checking that incoming data matches what the application expects before using it. Done well, it reduces attack surface and catches malformed or malicious input early. This lesson covers validation and its proper role.
Learning objectives
- Distinguish allowlist from denylist validation.
- Explain syntactic vs semantic validation.
- Understand validation's role alongside (not instead of) safe output handling.
Core concept
Validation checks input against expectations. Two philosophies:
- Allowlist (positive) validation — accept only input matching a known-good pattern (preferred). Everything not explicitly allowed is rejected.
- Denylist (negative) validation — try to block known-bad input (fragile; attackers bypass filters).
Validation also has levels: syntactic (right format/type/length — e.g. a valid email shape) and semantic (makes sense in context — e.g. a date not in the future). Validation should happen server-side (client-side is convenience only).
How it works
The application defines what valid input looks like and rejects anything that does not conform, ideally by allowlist. This shrinks the range of input the rest of the code must handle and catches obviously malicious or malformed data early. Crucially, validation is a first line of defense, not the whole defense: it does not by itself make input safe for every context. You still need context-specific safe handling — parameterized queries for databases, output encoding for HTML — because data valid for one purpose can still be dangerous in another.
Practical example
A registration form expects a username of 3–20 letters/digits. Allowlist validation accepts only ^[A-Za-z0-9]{3,20}$ and rejects everything else — far more robust than trying to blocklist bad characters. But even a validated username, when displayed on a page, must still be output-encoded to prevent XSS, and when stored, used via a parameterized query. Validation narrows the input; safe handling at each boundary finishes the job.
Cybersecurity relevance
Validation reduces attack surface and is part of defense in depth, but a frequent mistake is relying on validation alone to stop injection or XSS. Denylist filters are especially error-prone — attackers find encodings and cases the filter misses. The robust approach is allowlist validation plus context-appropriate safe handling (parameterization, encoding). Testers probe validation with unexpected input and filter-bypass techniques; defenders combine strict allowlists with safe output/query handling.
Common mistakes
- Using denylists ("block bad characters") instead of allowlists — easily bypassed.
- Treating validation as sufficient to prevent injection/XSS, skipping parameterization/encoding.
- Validating only client-side, which attackers bypass by sending requests directly.
Key takeaways
- Prefer allowlist (accept known-good) over denylist (block known-bad) validation, and validate server-side.
- Validation includes syntactic (format/type/length) and semantic (contextual sense) checks.
- Validation reduces attack surface but is not sufficient alone — combine it with context-specific safe handling (parameterized queries, output encoding).
Check your understanding
- Why is allowlist validation more robust than denylist validation?
- Why is input validation, by itself, not enough to prevent SQL injection or XSS?