Validating input and handling errors on the server: Full-Stack Development (Beginner)

Never trust the browser

Your React form may stop an empty title. But the API is just a URL. Anyone can call it with a tool like curl or Postman, or change the request in the browser's developer tools. Browser checks are for comfort. Server checks are for safety.

bash

curl -X POST https://notes.example.com/api/notes \
  -H 'Content-Type: application/json' \
  -b 'sid=...' \
  -d '{"title": "", "body": 12345, "pinned": "yes"}'

One command skips every check in your frontend. The server must reject this.

Think of it like this: A railway ticket checker does not trust the ticket because "the booking website checks everything". He checks your ticket and ID on the train himself. The website check makes booking smooth; the checker on the train keeps the journey safe. Your server is the ticket checker.

Validate and normalise

Validation means checking that the input follows the rules and rejecting it if not. Normalising means cleaning the input into one standard form before saving it: trimming spaces, lower-casing an email, filling in defaults. Normalise first where it matters (trim before checking the title length), then validate.

Field	Normalise	Rule
title	trim spaces at both ends	must be text, 1 to 100 characters after trimming
body	missing becomes ""	must be text, at most 5000 characters
pinned	missing becomes false	must be true or false (not "yes", not 1)
email (signup)	trim and lower-case	must look like an email; unique in users
password (signup)	do not change it at all	at least 8 characters (more rules in module 6)

javascript

import { z } from 'zod';

const NoteInput = z.object({
  title: z.string().trim().min(1, 'Title is required').max(100),
  body: z.string().max(5000).default(''),
  pinned: z.boolean().default(false),
});

const result = NoteInput.safeParse(req.body);
if (!result.success) {
  throw new AppError(400, 'VALIDATION_ERROR', result.error.issues[0].message);
}
const input = result.data; // trimmed title, defaults filled in

Zod is a popular schema library: you describe the shape once, and it validates and normalises in one step.

A schema library such as Zod lets you write the rules as a description instead of many if statements. You can write the checks by hand too (you will in the task below), and it is good to do it once to understand what the library does for you.

One error shape and the right status code

Status	When	Example code
400 Bad Request	The input breaks a rule, or the JSON is broken	VALIDATION_ERROR, INVALID_JSON
401 Unauthorized	Not logged in, or wrong email or password	UNAUTHORIZED
404 Not Found	The note does not exist or is not yours	NOT_FOUND
409 Conflict	The request clashes with existing data, such as an email already registered	EMAIL_TAKEN
500 Internal Server Error	A bug or a failure on our side	INTERNAL_ERROR

A central error handler

Instead of building error responses in every route, routes and services just throw an AppError (an error with a status and a code). One error-handling middleware at the end turns any error into the contract shape. Express knows it is an error handler because it takes four arguments: (err, req, res, next).

javascript

class AppError extends Error {
  constructor(status, code, message) {
    super(message);
    this.status = status;
    this.code = code;
  }
}

// Added AFTER all routes
app.use((err, req, res, next) => {
  if (err instanceof AppError) {
    return res.status(err.status).json({ error: { code: err.code, message: err.message } });
  }
  // Unknown error: log everything for us, show nothing private to the user
  console.error('Request failed', { method: req.method, path: req.path, err });
  res.status(500).json({ error: { code: 'INTERNAL_ERROR', message: 'Something went wrong. Please try again.' } });
});

Runs on the server. Known errors keep their status; unknown ones become a safe 500.

Tip: express.json() rejects a broken JSON body with an error whose type is "entity.parse.failed" and status 400. Handle it in the error handler and answer 400 INVALID_JSON instead of a 500.

Careful: Never send stack traces, SQL text or raw database errors to users. They show file paths, table names and library versions, which help attackers. Log the full details on the server (with the time and a request id) and send the user a short, safe message.

Validating input and handling errors on the server

Explanation

Never trust the browser

Validate and normalise

One error shape and the right status code

A central error handler

Watch the lesson

In real life: A UPI payment that fails safely

Practice (0/3 done)

Quick quiz

Read more (free)