Input Validation and Allowlisting

By Michael Samuel Naeem · May 23, 2025 · 5 min read

Your admin panel accepted sort=price; DROP TABLE users-- because the filter builder concatenated strings. Blocklists of SQL keywords lost to encoding tricks. Allowlisting accepts only price, created_at, and -name as sort keys—everything else returns 400 before touching the query builder. Input validation is not "sanitize HTML and hope"; it is defining the finite set of shapes your program can meaningfully process and rejecting the rest at the door.

Schema-first validation

import { z } from "zod";

const CreateUser = z.object({
  email: z.string().email().max(254),
  role: z.enum(["member", "admin"]),
  age: z.number().int().min(13).max(120),
});

const input = CreateUser.parse(req.body);

Parse, do not validate piecemeal after destructuring. Unknown keys: use .strict() to reject mass-assignment surprises.

Validate this in staging with production-like data volume before declaring done. Capture metrics baseline the week before change and compare for seven days after—subtle regressions hide in aggregates until a large tenant hits the path. Update the on-call runbook with the failure signature and rollback command so responders need not rediscover steps during an incident.

Allowlist enums and ranges

Reject unknown enum strings with problem details—do not coerce to default silently.

Validate this in staging with production-like data volume before declaring done. Capture metrics baseline the week before change and compare for seven days after—subtle regressions hide in aggregates until a large tenant hits the path. Update the on-call runbook with the failure signature and rollback command so responders need not rediscover steps during an incident.

Normalization before validation

Unicode normalization (NFC), trim whitespace, lowercase canonical forms for emails. Apply normalization once in middleware so downstream logic sees consistent input. Log raw and normalized values separately for fraud review.

Validate this in staging with production-like data volume before declaring done. Capture metrics baseline the week before change and compare for seven days after—subtle regressions hide in aggregates until a large tenant hits the path. Update the on-call runbook with the failure signature and rollback command so responders need not rediscover steps during an incident.

Injection-specific boundaries

• SQL: parameterized queries only; allowlist column names for dynamic ORDER BY
• Shell: never pass user input to exec; use library APIs
• Path: Path.resolve and verify result stays under upload root
• HTML: allowlist tags via sanitizer (DOMPurify server-side) if rich text required

ALLOWED_SORT = {"created_at", "amount", "status"}

def parse_sort(raw: str) -> tuple[str, str]:
    desc = raw.startswith("-")
    field = raw.lstrip("-")
    if field not in ALLOWED_SORT:
        raise ValidationError("invalid sort field")
    return field, "DESC" if desc else "ASC"

Validate this in staging with production-like data volume before declaring done. Capture metrics baseline the week before change and compare for seven days after—subtle regressions hide in aggregates until a large tenant hits the path. Update the on-call runbook with the failure signature and rollback command so responders need not rediscover steps during an incident.

File uploads

Validate magic bytes, not only extension. Allowlist image/jpeg, image/png, application/pdf. Re-encode images to strip EXIF and embedded payloads. Store outside web root; serve via signed URLs.

Validate this in staging with production-like data volume before declaring done. Capture metrics baseline the week before change and compare for seven days after—subtle regressions hide in aggregates until a large tenant hits the path. Update the on-call runbook with the failure signature and rollback command so responders need not rediscover steps during an incident.

Rate limit validation failures

Burst of 400s from one IP may indicate scanning. Alert on validation error spikes per route—distinct from 401 brute force.

Validate this in staging with production-like data volume before declaring done. Capture metrics baseline the week before change and compare for seven days after—subtle regressions hide in aggregates until a large tenant hits the path. Update the on-call runbook with the failure signature and rollback command so responders need not rediscover steps during an incident.

Fuzz JSON bodies with property-based tests. Include overlong strings, null bytes, surrogate pairs, and nested depth bombs. Security regression suite runs on every PR.

Fuzz JSON bodies with property-based tests. Include overlong strings, null bytes, surrogate pairs, nested depth bombs. Security regression suite runs every PR.

Rate limit validation failures—burst of 400s from one IP may indicate scanning. Alert separately from 401 brute force patterns.

Client validation improves UX; server validation is mandatory. Generate server schemas from one source and derive client types to avoid drift between TypeScript forms and API rules.

Validate this in staging with production-like data volume before declaring done. Capture metrics baseline the week before change and compare for seven days after—subtle regressions hide in aggregates until a large tenant hits the path. Update the on-call runbook with the failure signature and rollback command so responders need not rediscover steps during an incident.

Document the decision, owner, and rollback path in your team wiki the same week you ship. Future you will not remember which environment variable toggled the behavior unless it is written next to the runbook entry and linked from the alert. That habit costs ten minutes per change and saves hours when pagination or auth misbehaves under a single large tenant.

Resources

• OWASP Input Validation Cheat Sheet
• JSON Schema specification
• Zod documentation
• OWASP Mass Assignment Cheat Sheet
• CWE-20: Improper Input Validation