Validation at the Edge: Schemas, DTOs and Trusting Nothing

You already validate forms in the frontend. Backend validation is a different job. The browser's checks are a convenience for honest users. The server's checks are the security boundary. Anyone can call your API with curl (a command-line tool for sending HTTP requests) and send anything.

Words used in this lesson

• Validation means checking that data has the right shape and values before you use it. Example: qty must be a whole number from 1 to 100.
• The edge is the place where data first enters your program from outside, such as the HTTP request handler.
• A schema is a written description of what shape data must have: which fields, which types, which limits.
• Zod is a TypeScript library for writing schemas. It checks data at runtime (while the program runs) and also gives you the matching compile-time type (the type TypeScript checks before the program runs). TypeScript types disappear after compiling, so they cannot check data that arrives over the network. A runtime schema can.
• req.params, req.query and req.body are the parts of an Express request: values from the URL path (/orders/7), values after the ? in the URL, and the data sent in the request body.
• A constraint is a rule the database itself enforces. NOT NULL forbids empty values, UNIQUE forbids duplicates, CHECK tests a condition, and a foreign key requires that a reference points to a row that exists.
• An allow-list is a list of the only values you accept. Everything else is refused. (The opposite, a block-list, tries to list bad values and always misses some.)
• Authentication vs authorization: authentication asks "who are you?", and authorization asks "may you do this?".

Why validate on the server (and everywhere)

So, where should validation happen: client, server or database? The answer is all three, for different reasons. The server edge is the main guard.

Parse, don't validate

Parse, don't validate is a design idea. Do not just check a value and then keep passing around the same unchecked data. Instead, parse the raw input into a new value that is typed and trusted. After parsing, the rest of your code does not need more defensive checks.

import { z } from "zod";export const createOrderSchema = z.object({  items: z    .array(z.object({ sku: z.string().min(1).max(64), qty: z.number().int().min(1).max(100) }))    .min(1)    .max(50),  couponCode: z.string().trim().toUpperCase().max(32).optional(),  note: z.string().trim().max(500).optional(),}).strict(); // reject unknown fieldsexport type CreateOrderInput = z.infer<typeof createOrderSchema>; // the TypeScript type comes from the schema

z.infer is a Zod helper that reads a schema and produces the TypeScript type for it. By default, a Zod object removes unknown keys from the result without an error. .strict() makes unknown keys an error instead. So the schema is the single source of truth. It gives you both the runtime checks and the compile-time types. (Zod is one popular choice. Valibot, ArkType, Joi, Yup and TypeBox use the same idea.)

A reusable validation middleware

Middleware is a function that runs before your route handler. This one checks the params, query and body with schemas. safeParse is a Zod method that returns { success: true, data } or { success: false, error } instead of throwing.

import type { RequestHandler } from "express";import type { ZodTypeAny } from "zod";import { ValidationError } from "../shared/errors";export const validate =  (schemas: { body?: ZodTypeAny; query?: ZodTypeAny; params?: ZodTypeAny }): RequestHandler =>  (req, _res, next) => {    const issues: { where: string; path: string; message: string; code: string }[] = [];    for (const key of ["params", "query", "body"] as const) {      const schema = schemas[key];      if (!schema) continue;      const result = schema.safeParse(req[key]);      if (result.success) {        if (key === "body") req.body = result.data;       // replace with the parsed, typed value        else (req as any)[`valid${key[0].toUpperCase()}${key.slice(1)}`] = result.data;      } else {        for (const i of result.error.issues) issues.push({ where: key, path: i.path.join("."), message: i.message, code: i.code });      }    }    if (issues.length) return next(new ValidationError("Validation failed", issues));    next();  };

Query parameters and path params are strings

Everything in a URL arrives as a string. Convert values on purpose. In Zod, z.coerce.number() converts a string to a number before checking it:

export const listOrdersQuery = z.object({  status: z.enum(["pending", "paid", "shipped", "cancelled"]).optional(),  limit: z.coerce.number().int().min(1).max(100).default(20),  cursor: z.string().max(200).optional(),  sort: z.enum(["createdAt", "-createdAt", "total", "-total"]).default("-createdAt"),});export const idParams = z.object({ id: z.string().uuid() });

An allow-list enum (a fixed list of allowed values) for sort and status also protects against injection. Injection is an attack where someone sneaks code, such as SQL, into input so that your program runs it. Only known values reach the query builder.

Mass assignment (over-posting)

Mass assignment is a bug where the server copies every field from the request into a database record, so a client can set fields it should not. It is also called over-posting.

Scenario: the frontend sends an extra field, isAdmin: true. Look at this code:

// ❌ DANGEROUS: whatever the client sent goes straight into the databaseawait prisma.user.update({ where: { id }, data: req.body });

A bad client can now set fields you never meant to allow: isAdmin, role, balance, emailVerified, ownerId.

How to defend:

1. Allow only listed fields, using the schema. Build the update object from the parsed result (it contains only allowed keys). Never build it from raw req.body. Also, .strict() rejects unknown keys completely.
2. Use a separate schema for each use case. updateProfileSchema (name, avatar) is not the same as an admin's updateUserRoleSchema.
3. Never let the client decide who owns something, or set values that only the server should set. Take userId from the logged-in session (the server's record of who is logged in). Set timestamps and status on the server.
4. Keep the DTO separate from the database model. A DTO (data transfer object) is a plain object that has exactly the shape of the API contract. The database entity (the object for one stored row) has more: internal flags, hashes, audit fields. Map between them on purpose. Return only the fields you intend to show (never passwordHash).

const updateProfileSchema = z.object({ displayName: z.string().min(1).max(60), bio: z.string().max(280).optional() }).strict();const data = updateProfileSchema.parse(req.body);                 // only these two keys can passawait prisma.user.update({ where: { id: req.user!.id }, data });  // id comes from the session, not the body

Validation errors vs business-rule errors

Keep these two apart, because the client reacts in different ways:

Choose 400 or 422 for validation one time, and then stay consistent (HTTP semantics). Return paths, so the frontend can match each error to an input:

{ "status": 422, "title": "Validation failed",  "errors": [{ "path": "items.0.qty", "code": "too_small", "message": "Too small: expected number to be >=1" }] }

Share types and schemas with the frontend

The contract is the agreement about what the API accepts and returns. "Contract drift" is a classic bug: the two sides slowly stop matching. The backend changes a field, and the frontend breaks in production. Here are the options, from simplest to strongest:

1. A shared package in a monorepo (one repository that holds several projects, for example packages/schemas). It exports Zod schemas and inferred types. Both the Next.js app and the API import it. There is one definition, so the two sides cannot drift.
2. OpenAPI as the source of truth. OpenAPI is a standard file format that describes every endpoint of an API. You generate TypeScript types and clients from it (openapi-typescript). Or you use tRPC, a library that lets a TypeScript frontend call backend functions with shared types, for TypeScript-only stacks.
3. Generate the OpenAPI spec from the schemas (for example with zod-to-openapi), so the documentation is never out of date.

If the client uses the same schema, forms give instant feedback. The server still validates on its own.

Other input hygiene

• Limit the body size (express.json({ limit: "100kb" }); 100kb is also the default) and the number of array items. Input with no limit can be used for a denial-of-service attack (making your server too busy to answer).
• Check Content-Type. This header says what format the body is in (for example application/json). Reject types you do not expect with 415 (Unsupported Media Type). Note that express.json() skips a body with another type and leaves req.body empty, so add this check yourself.
• Validate and clean early: trim strings, lowercase emails, and convert dates to Date one time.
• Sanitise only where it makes sense. Sanitising means cleaning input, for example by removing characters. Validation decides whether the data is acceptable. Escaping/encoding means changing special characters so they are treated as plain text, and it happens at output (HTML, SQL parameters). Do not try to remove "bad characters" as your security plan.
• Use parameterised queries. A parameterised query sends the SQL text and the values separately, so a value can never be run as SQL. Use the ORM (a tool that lets you use the database from code) or $1 placeholders. Never build SQL by joining strings. (Prisma's tagged $queryRaw template is parameterised. $queryRawUnsafe with interpolation is not.)
• Validate files: size, declared type, detected type and extension. Store them outside the web root (the folder the web server serves directly) or in object storage (a service for storing files, such as Amazon S3) (Practical Design Problems, Lesson 04).
• Validate configuration at startup (env.ts with a schema). If a secret is missing, the process crashes right away, not at 3 a.m.:

export const env = z.object({  NODE_ENV: z.enum(["development", "test", "production"]),  PORT: z.coerce.number().default(3000),  DATABASE_URL: z.string().url(),  JWT_PUBLIC_KEY: z.string().min(1),}).parse(process.env);

• Let the database enforce the rules too: UNIQUE (email), CHECK (qty > 0), NOT NULL, foreign keys. Application checks can race. A race condition happens when two requests run at the same time and both pass a check such as "does the email exist?", before either one saves. A unique constraint cannot be beaten this way, because the database applies it atomically (as one indivisible step). Catch the constraint error and turn it into a 409.

Common mistakes

1. Trusting the frontend's validation.
2. Spreading req.body into database writes (mass assignment).
3. Validating, but then using the original untyped input instead of the parsed result.
4. No size limits on bodies, arrays and strings.
5. Forgetting that query and path params are strings ("0" and "false" are non-empty strings, so both are truthy, and neither is a number or a boolean).
6. Mixing validation errors and business errors and returning the same status for both.
7. Check-then-insert races with no unique constraint behind them.
8. Hand-written regexes (regular expressions, text patterns) for emails and URLs instead of tested libraries and new URL().

Interview questions

Key takeaways

• Validate at the edge, on the server, always. Client checks are for user experience, not security.
• Parse into typed objects with a schema, and let z.infer give you the types.
• Defend against mass assignment with strict schemas for each endpoint and fields that only the server sets.
• Keep validation errors and business-rule errors apart, and return field paths.
• Share schemas (monorepo or OpenAPI) so the frontend and backend cannot drift.
• Limit sizes, parameterise queries, validate config at startup, and back everything with database constraints.

What's next

Lesson 04: Error Handling: Operational vs Programmer Errors. Inputs are checked. Now, what happens when things still go wrong? We look at typed errors, central handling, how Express 5 handles async code, and when to let the process crash.