Input validation

The OWASP Input Validation Cheat Sheet distinguishes syntactic validation, which enforces the correct form of a value (a Danish CPR number is ten digits, a date parses as ISO 8601, a quantity is an integer), from semantic validation, which enforces correctness in the business context (a start date precedes the end date, a quantity is between 1 and 99, the referenced account belongs to the caller). Both should run on the server at the trust boundary, as early as possible, before the data reaches business logic or storage. Client-side checks improve usability but provide no security, because any HTTP client can bypass them. NIST SP 800-53 Rev. 5 captures the same control as SI-10 Information Input Validation, and the corresponding weakness is CWE-20 Improper Input Validation.

Allowlisting defines what is acceptable, through a type, an enumeration, a length bound, a numeric range or an anchored regular expression, and rejects everything else. Denylisting known-bad strings such as script tags or SQL keywords is brittle: attackers bypass it with alternative encodings, case changes, comments and Unicode look-alikes. Input should be decoded and canonicalised (URL decoding, Unicode normalisation such as NFC or NFKC, path resolution) before it is validated, otherwise a check on "../" can be bypassed with %2e%2e%2f or overlong encodings. Regular expressions themselves can become a denial-of-service vector: patterns with nested quantifiers can backtrack catastrophically on crafted input (ReDoS), so length limits should be applied first.

Structured inputs are best validated against a schema: JSON Schema or OpenAPI for API bodies, XSD for XML with DTDs and external entities disabled to prevent XXE, and strict binding to explicit data-transfer objects so extra properties are rejected, which also prevents mass assignment. File uploads need a size limit, an allowlist of extensions checked together with the actual content signature rather than the client-supplied Content-Type, server-generated file names and storage outside the web root.

The most important limitation is that validation is not a substitute for context-specific output handling. A string can be perfectly valid, such as the surname O'Neil or a free-text comment containing angle brackets, and still be dangerous in a SQL statement or an HTML page. Injection is prevented at the point of use through parameterised queries, contextual output encoding and safe APIs; validation reduces the attack surface and catches malformed data early. The same applies to data from internal services, databases and LLM outputs, which should be treated as untrusted when they originate outside the component's own control.