Input sanitisation

Treat all input as hostile: validate its shape, bound its size, and escape it for wherever it goes next, whether HTML, SQL, a shell or a log line. Each destination has its own rules.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain why escaping depends on where the data goes next
Validate shape and bound size before processing input
Escape a value for HTML, SQL and a shell at the point of use

In practice

A few lines that show Input sanitisation doing its job.

JavaScript

import { escape } from "node:querystring";

// HTML output: escape at render time, never trust stored strings
const safe = (s) => s.replace(/[&<>"']/g, (c) =>
  ({ "&": "&amp;", "<": "&lt;", ">": "&gt;", '"': "&quot;", "'": "&#39;" })[c]);

// Shell: pass arguments, never a command string
import { execFile } from "node:child_process";
execFile("convert", [userFilename, "out.png"], callback);

The common mistake

Watch for

Sanitising on input and then trusting the data everywhere. One field escaped for HTML is still dangerous in a shell command; escape for the context at the point of use.

What to know first

Your roadmap puts these before Input sanitisation, unless you already know them.

Request validation

How it stays learned

Once a session shows you understand Input sanitisation, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

Previous in the module← Role-based access

Next in the moduleRate limiting →