Input Validation: Allowlist, Server-Side, and Why It Is Not Enough

What Is Input Validation?

Input validation is checking that incoming data matches the expected type, length, format, and range before your application does anything with it. A postcode should look like a postcode. An age should be a positive integer in a sane range. A username should match a defined character set and length. Anything that does not fit gets rejected at the door.

The point is to shrink the attack surface. Every field that accepts arbitrary bytes is a field an attacker can probe. Validation narrows what each field will even accept, so a lot of malformed and malicious input never reaches the logic behind it.

Allowlist vs Denylist

Use an allowlist: define exactly what is valid and reject everything else. The opposite approach, a denylist that enumerates known-bad patterns and blocks them, is the single most common way validation goes wrong.

A denylist that strips <script> misses <img onerror>, <svg onload>, mixed-case <ScRiPt>, and a dozen encodings you did not think of. You are playing whack-a-mole against an attacker who only has to find one gap. An allowlist flips the burden: a username matched against ^[a-z0-9_]{3,20}$ rejects every payload that is not lowercase letters, digits, or underscores, including attacks that did not exist when you wrote the rule. It fails closed.

Validate on the Server

All security validation runs server-side. Client-side checks in the browser are good for user experience, instant feedback before a round trip, but they are trivially bypassed. An attacker does not use your form; they call your API directly with curl and send whatever they want.

// Client-side validation only - bypassed in seconds:
curl -X POST https://example.com/api/profile \
  -d 'username=<svg onload=alert(1)>'
// The browser form would have blocked this. The API did not.

Treat client-side validation as convenience and server-side validation as the boundary. If you can only do one, do the server.

Validation Is Not the Whole Fix

Here is the part that trips people up. Validation reduces risk, but it is not what stops injection. SQL injection is stopped by parameterized queries, which keep data and code separate no matter what the data contains. XSS is stopped by context-aware output encoding, applied when data is written into a page. Validation works alongside those as defense in depth.

The reason the distinction matters: plenty of valid input is still dangerous in the wrong context. The name O'Brien is a perfectly valid name and a perfectly good way to break a string-concatenated SQL query. Validation lets it through, correctly, because it is real data. Parameterization is what keeps it from becoming code.

A Practical Checklist

• Allowlist every field by type, length, format, and range. Reject, do not sanitize, when you can.
• Validate server-side on every request, treating client checks as UX only.
• Validate at the boundary, as data enters the system, not scattered deep in the logic.
• Pair with parameterized queries and output encoding, so a valid-but-dangerous value cannot turn into an injection.
• Normalize before you validate, decoding and canonicalizing input first so an encoded payload cannot slip past the check.

Test Your Site

Validation bugs surface when you send the input the developer assumed would never arrive: wrong type, absurd length, an encoded payload, a missing field. We built ismycodesafe after watching how reliably AI-assisted code generates the optimistic version of a handler, the one that trusts the request shape and validates nothing, because the prompt asked for the feature, not the guard. Our scanner probes your live endpoints for the configuration and response patterns that give this away.

Scan My Website — Free