✅ Input Validation with Express-validator

Why Validate on the Server?

Client-side validation — the red text that appears under a form field — is a user experience feature. It gives instant feedback and saves a round trip. But it is not security, because anyone can bypass it: disable JavaScript, use curl, or call your API directly with Postman. The browser is not your gatekeeper. Your server is.

Think of it like airport security. The friendly reminder signs before the checkpoint (client-side) help travelers prepare, but the actual screening (server-side) is what keeps dangerous things off the plane. You screen every passenger regardless of what the signs said. Validate every request regardless of what the front end claims it sent.

• Security — reject injection payloads, malformed data, and oversized input before they do harm
• Data integrity — guarantee that what reaches your database matches your schema's expectations
• Stability — a missing field or wrong type won't throw deep inside your logic where it's hard to trace
• Clear feedback — return precise, per-field errors clients can act on

express-validator is a set of Express middleware wrapping the battle-tested validator.js library. It lets you declare rules as fluent chains that read almost like English.

The Validate → Sanitize → Handle Pipeline

Every validated route follows the same three-stage flow. Requests enter, get checked and cleaned, and only valid ones reach your handler; invalid ones peel off into a 400 response.

First install the package:

// npm install express-validator

Here's the whole pipeline in one route so you can see the shape before we break it down:

const express = require('express');
const { body, validationResult } = require('express-validator');
const app = express();
app.use(express.json());

app.post(
  '/api/users',
  // 1) Validate + sanitize (each is a middleware in the chain)
  body('name').trim().notEmpty().withMessage('Name is required'),
  body('email').trim().isEmail().withMessage('Valid email required').normalizeEmail(),
  body('password').isLength({ min: 8 }).withMessage('Min 8 characters'),
  // 2) Handle — inspect the collected results
  (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).json({ errors: errors.array() });
    }
    // 3) Only valid, cleaned data reaches here
    res.status(201).json({ message: 'User created', user: req.body });
  }
);

app.listen(3000, () => console.log('Running on 3000'));

Notice validation rules are just middleware you pass before the handler. They run in order, accumulate any problems on the request, and your handler decides what to do with them.

Validation Chains

A validation chain starts by naming a field from a request location, then fluently appends rules. Each rule returns the chain, so they read top-to-bottom like a checklist. The location functions are body(), param(), query(), header(), and cookie().

const { body, param, query } = require('express-validator');

// Body field: presence, then length
body('username')
  .trim()
  .notEmpty().withMessage('Username is required')
  .isLength({ min: 3, max: 20 }).withMessage('Must be 3-20 characters');

// URL parameter: numeric id
param('id')
  .isInt({ min: 1 }).withMessage('id must be a positive integer')
  .toInt();

// Query string: optional pagination limit
query('limit')
  .optional()
  .isInt({ min: 1, max: 100 }).withMessage('limit must be 1-100')
  .toInt();

express-validator ships dozens of validators. A sampler of the most common:

Checking the Result

The chains only gather findings — they never respond on their own. To act on them, call validationResult(req), which returns a result object. Its .isEmpty() tells you if everything passed, and .array() gives the list of failures.

const { validationResult } = require('express-validator');

app.post('/api/users', /* ...chains... */ (req, res) => {
  const result = validationResult(req);
  if (!result.isEmpty()) {
    return res.status(400).json({ errors: result.array() });
  }
  // proceed with valid data
});

{
  "errors": [
    { "type": "field", "path": "email",
      "location": "body", "value": "not-an-email",
      "msg": "Valid email required" },
    { "type": "field", "path": "password",
      "location": "body", "value": "123",
      "msg": "Min 8 characters" }
  ]
}

You can reshape that output with .formatWith() to match your API's conventions — for example, a slimmer { field, message } object per error:

const errors = validationResult(req).formatWith(({ path, msg }) => ({
  field: path,
  message: msg
}));

if (!errors.isEmpty()) {
  return res.status(400).json({ success: false, errors: errors.array() });
}

Sanitization

Validation asks "is this acceptable?" Sanitization asks "let me clean this up first." Sanitizers transform the value in place, so by the time your handler reads req.body, the data is already normalized. Run sanitizers before validators in the chain so you validate the cleaned value.

body('name')
  .trim()                    // strip leading/trailing whitespace
  .escape()                  // convert <, >, &, ", ' to HTML entities
  .notEmpty().withMessage('Name is required');

body('email')
  .trim()
  .normalizeEmail()          // lowercase domain, canonicalize
  .isEmail().withMessage('Valid email required');

body('age')
  .toInt();                  // "42" (string) becomes 42 (number)

body('subscribe')
  .toBoolean();              // "true"/"1" becomes true

Custom & Conditional Validators

Built-in validators cover the common cases, but real apps have business rules: "this email must be unique," "confirm password must match," "shipping address is required only for physical products." That's what .custom() is for. A custom validator receives the value (and a context with req), returns true to pass, or throws / returns a rejected promise to fail.

Cross-field validation

body('passwordConfirm')
  .custom((value, { req }) => {
    if (value !== req.body.password) {
      throw new Error('Passwords do not match');
    }
    return true;                 // explicit pass
  });

Async custom validators (e.g. uniqueness)

body('email')
  .isEmail().withMessage('Valid email required').bail()
  .custom(async (email) => {
    const existing = await User.findOne({ email });
    if (existing) {
      // A rejected promise fails the validation with this message
      throw new Error('Email is already registered');
    }
    return true;
  });

Conditional rules with .if()

// Only validate shippingAddress when the order is physical
body('shippingAddress')
  .if(body('productType').equals('physical'))
  .notEmpty().withMessage('Shipping address is required for physical goods');

Reusable Validation Middleware

Sprinkling validationResult checks into every handler repeats the same six lines everywhere. Extract that into one validate middleware, then group each route's chains into an exported array. Routes become a clean list: rules, the checkpoint, the handler.

// middleware/validate.js
const { validationResult } = require('express-validator');

// One checkpoint: if any chain failed, respond 400; else continue.
function validate(req, res, next) {
  const errors = validationResult(req);
  if (!errors.isEmpty()) {
    return res.status(400).json({
      success: false,
      errors: errors.array().map(({ path, msg }) => ({ field: path, message: msg }))
    });
  }
  next();
}

module.exports = validate;

// validators/user.js
const { body } = require('express-validator');

const registerRules = [
  body('name').trim().notEmpty().withMessage('Name is required')
    .isLength({ min: 2, max: 50 }).withMessage('Name must be 2-50 characters'),
  body('email').trim().normalizeEmail()
    .isEmail().withMessage('Valid email required'),
  body('password').isLength({ min: 8 }).withMessage('Min 8 characters')
    .matches(/\d/).withMessage('Must contain a number'),
  body('passwordConfirm').custom((v, { req }) => {
    if (v !== req.body.password) throw new Error('Passwords do not match');
    return true;
  })
];

module.exports = { registerRules };

// routes/users.js
const express = require('express');
const router = express.Router();
const validate = require('../middleware/validate');
const { registerRules } = require('../validators/user');
const controller = require('../controllers/user');

// rules → checkpoint → handler
router.post('/register', registerRules, validate, controller.register);

module.exports = router;

Now each route reads as intent: "apply these rules, run the checkpoint, then do the work." Adding a field means editing one array; the checkpoint never changes.

Practice & Quiz

const { body } = require('express-validator');

const registerRules = [
  body('username')
    .trim()
    .isLength({ min: 3, max: 20 }).withMessage('Username must be 3-20 characters')
    .matches(/^\w+$/).withMessage('Letters, numbers and underscore only'),

  body('email')
    .trim()
    .normalizeEmail()
    .isEmail().withMessage('Valid email required'),

  body('age')
    .optional()
    .isInt({ min: 13, max: 120 }).withMessage('Age must be 13-120')
    .toInt(),

  body('acceptTerms')
    .equals('true').withMessage('You must accept the terms')
];

module.exports = { registerRules };

body('price')
  .notEmpty().withMessage('Price is required').bail()
  .isFloat({ min: 0.01 }).withMessage('Price must be at least 0.01')
  .toFloat();

Best Practices & Pitfalls

✅ Do

• Validate every input source: body, params, query, and any headers you trust
• Sanitize before you validate — .trim(), .normalizeEmail(), .toInt()
• Extract chains into reusable arrays and use one shared validate checkpoint
• Use .optional() for update endpoints where fields may be absent
• Add .bail() before expensive checks like database uniqueness lookups

❌ Don't

• Trust client-side validation as a security boundary
• Forget the validationResult check — chains alone never block a bad request
• Escape passwords or exact-match fields with .escape()
• Read error.param in v7 code — it's error.path now
• Return the raw invalid value back in errors for sensitive fields (like passwords)

Summary

📚 Additional Resources

• express-validator — Official documentation
• express-validator — The validation chain
• validator.js — the underlying validators
• OWASP — Input Validation Cheat Sheet

🚀 What's Next?

You're now throwing Error objects and setting statusCode by hand all over the place. The next lesson cleans that up for good: Custom Error Classes, where you'll build an AppError hierarchy — ValidationError, NotFoundError, and friends — so throwing the right error with the right status becomes a single, self-documenting line.