Never Trust User Input: The Validation Mindset

WHY IT EXISTS: Input validation exists to protect an information system from receiving malformed or malicious data. Without it, bad data can persist in a database, trigger malfunctions in downstream components, or open security holes for attacks like SQL injection and Cross-Site Scripting (XSS).

THE MENTAL MODEL: Treat all data crossing a trust boundary as hostile until proven otherwise. Your job is not to guess all the possible "bad" inputs (denylisting), but to define a strict, narrow definition of what is "good" (allowlisting) and reject everything else. Validation is a gatekeeper, not a filter.

HOW IT WORKS: Validation is implemented by enforcing rules on data as early as possible, preferably the moment it is received from an external source. The most robust strategy is the allowlist, which defines the exact format of acceptable data using tools like regular expressions, type checking, and range constraints. For example, a numeric ID field should only accept integers. Anything that does not strictly match the allowlist rule is rejected outright.

WHEN TO USE IT: Use input validation on all data from potentially untrusted sources. This includes not only public-facing web clients submitting forms, but also API requests, backend data feeds from suppliers or partners, and file uploads. If your system did not generate the data itself, it must be validated.

WHEN NOT TO USE IT: The principle of validation is universal, but its strictness can vary. For data moving between two services you control within a secure private network, you might have a different threat model than for a public API. Even then, schema and type validation is a best practice to prevent bugs and ensure data integrity. Never blindly trust external data.

ONE CANONICAL EXAMPLE: A user registration form requires a postal code, which for a specific region must be exactly five digits. The allowlist validation rule would be a regular expression like /^[0-9]{5}$/. If a user enters "12345", it passes. If they enter "ABCDE" or "12345-6789", the validation fails, and the system rejects the input immediately, preventing non-numeric or incorrectly formatted data from ever reaching the application logic or database.