Express.js Validation and Sanitization: Stop Bad Input At The Boundary

Untrusted Input Boundary

Validation is one of the fastest ways to make an API feel trustworthy.

If the request boundary accepts anything, the rest of the application is forced to deal with avoidable chaos later.

Beginners often think validation is only about required fields. Professionals know it also protects business rules, debugging clarity, and security posture.

Sanitization belongs nearby because accepted input should be normalized before it spreads further into the system.

What Validation Protects Beyond Syntax

At first, validation looks like a checklist: field present, email shaped correctly, number inside range. But its real value is bigger. Validation protects the business from impossible states and protects developers from guessing what kind of data reached a service function.

When bad input is rejected early, the rest of the code gets simpler. Services can assume more. Logs become clearer. Client errors become easier to explain.

Validate type, shape, and required fields.
Validate business constraints where appropriate.
Fail early so bad input does not spread.

Why Sanitization Matters Too

Sanitization is about cleaning and normalizing data that you do decide to accept. That might mean trimming spaces, normalizing casing, stripping fields the client should not control, or transforming values into a safer internal shape.

Without sanitization, two values that mean the same thing may be stored inconsistently. That creates subtle bugs in search, comparison, deduplication, and reporting.

Trim or normalize accepted text fields.
Ignore or strip fields users should not set directly.
Create a stable internal payload shape before calling business logic.

Build A Validation Boundary

Validation answers whether input has the expected shape and meaning. Define a schema for body, path parameters, and query parameters before the controller runs. Check required fields, types, allowed values, formats, length limits, numeric ranges, and cross-field rules. Reject unknown fields for sensitive writes so clients cannot mass-assign internal properties.

Parsing and validation are separate. JSON parsing can fail before a schema sees the body. Query parameters arrive as strings and should be converted deliberately rather than through surprising truthy rules. Normalize email casing or whitespace only when the business meaning allows it, and preserve the original value when auditing matters.

The validation middleware should produce a typed or trusted value for downstream code. Store it in a clear request property or pass it directly to the controller. Services should not repeat HTTP parsing, but important domain invariants still belong in the service or database because requests are not the only way business operations may run.

Validate body, params, and query independently.
Reject unknown write fields where appropriate.
Convert strings with explicit rules.
Pass validated data rather than the raw request body.
Keep business invariants below the HTTP layer.

What Mature APIs Do With Errors

A strong validation layer does not only reject input. It explains why the input failed in a way the client can act on. Generic error messages waste time for frontend developers and frustrate users.

Professional teams also keep validation errors structured and consistent so logs, dashboards, and consuming apps can reason about them predictably.

Return field-aware errors where helpful.
Keep error shapes stable across endpoints.
Avoid leaking internal implementation details in validation responses.

Validate at the HTTP Boundary

Validate a registration payload with explicit types, length limits, allowed values, and cross-field rules before it reaches the service. Return field-level errors without echoing secrets.

Coercion can turn surprising strings into booleans or numbers, and sanitizing SQL input is not a substitute for parameterized queries. Unknown fields can also become mass-assignment vulnerabilities.

Verification must use evidence that matches the concept. Test empty, oversized, malformed, duplicate, and unknown fields; assert the service is not called when validation fails. Repeat the check after deliberately introducing the failure, then after the fix. The contrast between those runs is the part that turns a definition into practical understanding.

Security, Error Contracts, And Resource Limits

Sanitization should be context-specific. Parameterized SQL protects database queries; HTML escaping protects rendering; URL validation protects outbound requests. A generic function that removes suspicious characters can corrupt valid names while failing to prevent injection in the actual sink. Validate structure, then encode or parameterize at the point of use.

Apply body-size limits, collection limits, string limits, recursion limits, and request timeouts before expensive processing. Validate uploaded file signatures rather than trusting extensions. For URLs, control schemes, DNS resolution, redirects, and private network ranges to reduce server-side request forgery risk.

Return a stable error contract with a machine-readable code, human message, field path, and correlation ID. Do not expose stack traces, SQL details, tokens, or the complete rejected secret. Track validation failure rates by endpoint and rule because sudden changes can reveal broken clients, abuse, or an incompatible deployment.

Sanitize for the destination context.
Use parameterized queries and output encoding.
Bound payload size and structural complexity.
Design stable field-level error responses.
Monitor validation failures without logging secrets.

Validate Every Source

Request data comes from path parameters, query strings, headers, cookies, and parsed bodies. Give each source its own schema and merge only the validated result. Query values commonly arrive as strings or arrays, so coercion must be explicit: decide whether "01" is a valid integer representation, whether repeated keys are allowed, and how an empty string differs from omission or null.

Treat req.body as untrusted even after express.json parses it. Parsing proves JSON syntax, not object shape, key ownership, depth, or business meaning. Reject unknown keys for mutation commands when silent acceptance would hide client mistakes or mass-assignment risk. Build a new plain validated object rather than passing the original body into a model, ORM, template, or merge utility.

Structural Limits

Set parser byte limits before validation and schema limits for strings, arrays, object depth, key count, and numeric range. A small compressed request can inflate into much more work, and a valid array with hundreds of thousands of items can exhaust CPU or database parameters. Use route-specific parsers or preflight controls for endpoints with genuinely different payload needs.

Normalization Boundary

Normalize only when multiple forms have the same business meaning: trim surrounding whitespace for a code if spaces are never significant, canonicalize an email according to the application rule, and parse a date only with an accepted format and timezone policy. Do not strip punctuation globally or lowercase passwords, display names, signed values, or opaque identifiers.

Cross-Field and Database Rules

Schema validation can compare fields such as start before end, but availability, uniqueness, balance, and workflow transition depend on current durable state. Enforce those rules in a transaction and back concurrency-sensitive conditions with constraints or conditional updates. A preflight uniqueness query improves the message but cannot prevent two requests from passing together.

Outbound Validation

Validate data received from databases, queues, configuration, and third-party APIs at the boundary where corruption would be costly. This is especially important during rolling schema changes. Serialize responses through an explicit resource schema so a newly added database column or internal flag cannot leak merely because an object is spread into JSON.

Failure Test Matrix

Test omitted, null, empty, wrong-type, malformed, boundary, and oversized values.
Test repeated query keys, unknown body keys, deep nesting, and large collections.
Test a semantically valid request that loses a uniqueness or state race.
Assert no database write, job, upload, or external call occurs after rejection.
Assert error logs and responses exclude secrets and full sensitive payloads.

A clean boundary flow

This flow keeps application logic calmer downstream.

A clean boundary flow

Receive payload -> validate shape and rules -> sanitize accepted fields -> reject or continue -> call service with a trusted input object

The service should not need to second-guess every field.
Validation failures should be understandable to clients.
Sanitization should happen before persistence and business logic.

Validate an Express request with Zod

Parse each request source and pass only trusted values onward.

Validate an Express request with Zod

const createUser = z.object({
  email: z.string().email().max(254).transform(v => v.toLowerCase()),
  password: z.string().min(12).max(128),
  role: z.enum(['user', 'editor']).default('user')
}).strict();

const result = createUser.safeParse(req.body);
if (!result.success) return next(new ValidationError(result.error));
req.validatedBody = result.data;
next();

strict rejects unknown fields.
Do not log the password on failure.
Use the parsed result, not req.body.

Consistent validation error response

Map library-specific errors into an API-owned contract.

Consistent validation error response

{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "One or more fields are invalid.",
    "requestId": "req_01J...",
    "fields": [
      {"path": "email", "code": "invalid_email"}
    ]
  }
}

Keep codes stable even if wording changes.
Use field paths clients can map to controls.
Exclude submitted secrets from the response.

Before you move on