Validation

Never trusting request data - validating request bodies with Zod, the express-validator alternative, and returning useful error messages.

What it is, in plain English: Validation means checking that incoming request data (body, query, params) matches what your route handler expects before acting on it -- correct types, required fields present, values within acceptable ranges. Without validation, malformed or malicious input can crash your server, corrupt your database, or open security holes. Zod is the most popular modern choice for Express APIs -- it defines a schema once and uses it for both validation and TypeScript types.

Never trusting what arrives in a request

The golden rule: validate everything from the client. Request bodies, query strings, and route parameters can contain anything -- missing fields, wrong types, malicious content. Always validate before using them.

What happens without validation

// Looks fine until someone sends bad data:
app.post("/users", (req, res) => {
  const user = createUser(req.body.name, req.body.email, req.body.age);
  res.status(201).json(user);
});

// What if req.body.age is the string "twenty" instead of a number?
// What if req.body.email is missing entirely?
// What if req.body.name is 10,000 characters long?
// Without validation, your server either crashes or silently stores bad data.

Validation with Zod -- the modern standard

// npm install zod
import { z } from "zod";

const userSchema = z.object({
  name:  z.string().min(1, "Name is required").max(100),
  email: z.string().email("Must be a valid email address"),
  age:   z.number().int().min(0).max(150),
});

app.post("/users", (req, res) => {
  const result = userSchema.safeParse(req.body);

  if (!result.success) {
    return res.status(400).json({ errors: result.error.issues });
  }

  // result.data is now guaranteed valid AND correctly typed:
  const user = createUser(result.data);
  res.status(201).json(user);
});

Common schema building blocks

z.string()                          // must be a string
z.string().min(3).max(50)           // length constraints
z.string().email()                  // must look like an email
z.string().url()                    // must be a valid URL
z.number().int().positive()         // whole positive numbers only
z.boolean()                          // true/false
z.enum(["admin", "user", "guest"])  // must be one of these exact values
z.array(z.string())                  // an array of strings
z.string().optional()                // field can be omitted
z.string().default("guest")          // fills in a default if omitted

Try It Yourself (Node.js logic)

// Validation -- checking request data before trusting it
// (Zod needs npm install zod -- logic demonstrated with plain JS here)

// Why validation matters -- what happens WITHOUT it:
function createUserUnsafe(body) {
  // No checks -- assumes body.email and body.age are always correct shape:
  return { email: body.email.toLowerCase(), age: body.age + 1 };
  // body.email undefined -> crashes on .toLowerCase()
  // body.age "twenty" -> "twenty1" (string concatenation, not addition!)
}

try {
  createUserUnsafe({ age: "twenty" });  // missing email
} catch (e) {
  console.log("Crashed:", e.message);
}

console.log("Without validation:", createUserUnsafe({ email: "A@B.COM", age: "20" }));
// Bug: age becomes "201" (string concat) instead of 21 (number addition)!

// A simplified validation function (what Zod does, conceptually):
function validateUser(data) {
  const errors = [];

if (typeof data.email !== "string" || !data.email.includes("@")) {
    errors.push({ field: "email", message: "Must be a valid email" });
  }
  if (typeof data.age !== "number" || data.age < 0 || data.age > 150) {
    errors.push({ field: "age", message: "Must be a number between 0 and 150" });
  }
  if (typeof data.name !== "string" || data.name.trim().length === 0) {
    errors.push({ field: "name", message: "Name is required" });
  }

return { valid: errors.length === 0, errors };
}

console.log("\nValidating { name: 'Alice', email: 'alice@example.com', age: 30 }:");
console.log(validateUser({ name: "Alice", email: "alice@example.com", age: 30 }));

console.log("\nValidating { email: 'not-an-email', age: 'twenty' }:");
console.log(validateUser({ email: "not-an-email", age: "twenty" }));

// THE REAL ZOD PATTERN (reference code):
const ZOD_EXAMPLE = `
import { z } from "zod";

const createUserSchema = z.object({
  name:  z.string().min(1, "Name is required"),
  email: z.string().email("Must be a valid email"),
  age:   z.number().int().min(0).max(150),
});

app.post("/users", validate(createUserSchema), (req, res) => {
  // req.body is now guaranteed to match the schema
  res.status(201).json(createUser(req.body));
});
`;
console.log("\nZod validation middleware pattern:");
console.log(ZOD_EXAMPLE.trim());

Reusable validation middleware and nested schemas

A reusable validation middleware factory

function validate(schema, source = "body") {
  return (req, res, next) => {
    const result = schema.safeParse(req[source]);

    if (!result.success) {
      return res.status(400).json({
        error: "Validation failed",
        details: result.error.issues.map(issue => ({
          field:   issue.path.join("."),
          message: issue.message,
        })),
      });
    }

    req[source] = result.data;   // replace with parsed/coerced data
    next();
  };
}

// Apply to body, query, or params independently:
const createUserSchema = z.object({ name: z.string(), email: z.string().email() });
const listQuerySchema  = z.object({ page: z.coerce.number().default(1) });

app.post("/users",  validate(createUserSchema),          handler);
app.get("/products", validate(listQuerySchema, "query"), handler);

Nested and complex schemas

const addressSchema = z.object({
  street: z.string(),
  city:   z.string(),
  zip:    z.string().regex(/^\d{6}$/, "ZIP must be 6 digits"),
});

const orderSchema = z.object({
  customerName: z.string().min(1),
  items: z.array(z.object({
    productId: z.string(),
    quantity:  z.number().int().positive(),
  })).min(1, "Order must have at least one item"),
  shippingAddress: addressSchema,
  notes: z.string().optional(),
});

// One schema validates the ENTIRE nested request body shape in one call

Custom validation rules with .refine()

const passwordSchema = z.object({
  password:        z.string().min(8),
  confirmPassword: z.string(),
}).refine(data => data.password === data.confirmPassword, {
  message: "Passwords do not match",
  path:    ["confirmPassword"],   // attaches the error to this field
});

const signupSchema = z.object({
  username: z.string().min(3),
}).refine(async (data) => {
  const exists = await db.users.findOne({ username: data.username });
  return !exists;
}, { message: "Username already taken" });

express-validator alternative and sanitization vs validation

// express-validator -- an alternative, chainable validation style:
// npm install express-validator
import { body, validationResult } from "express-validator";

app.post("/users",
  body("email").isEmail().normalizeEmail(),
  body("name").trim().isLength({ min: 1, max: 100 }).escape(),
  body("age").isInt({ min: 0, max: 150 }).toInt(),
  (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).json({ errors: errors.array() });
    }
    // req.body is now validated AND sanitized (normalizeEmail, trim, escape)
    res.status(201).json(createUser(req.body));
  }
);

// Zod vs express-validator:
// Zod: schema-first, reusable for TypeScript types, composable
// express-validator: chainable per-field, built-in sanitizers (escape, trim, normalizeEmail)

Validation vs sanitization -- a critical distinction

Validation rejects bad input — it answers "is this acceptable?" and either accepts or refuses the request. Sanitization transforms input into a safe form — trimming whitespace, escaping HTML, normalizing email casing. Both matter, but they solve different problems: validation alone doesn't stop a technically-valid string like <script>alert(1)</script> from being stored and later rendered unsafely (an XSS vulnerability) — that requires sanitization or output-encoding at render time, not just input validation. Always validate at the API boundary AND properly escape output wherever user content is displayed; neither alone is a complete defense.

Official Sources

The Codex links only to official documentation. No third-party tutorials.