FSD Frontend System Design

Part II — The Shield · Lesson 3.9

Input Validation and Sanitization

In one lineValidate shape on the way in, escape by context on the way out — they are different jobs.

Where you've seen itA rich-text comment editor that must preserve <b> and links while dropping <script> and every on* attribute.

  • Time15 min
  • DiagramInput → validate → store raw → escape on output
  • Chapter3 · Security

Diagram

diagram
THE PIPELINE — store raw, transform at the boundary

  user input
      │
      ▼
  ┌──────────────┐   reject if wrong TYPE, LENGTH, FORMAT, RANGE
  │  VALIDATE    │   "is this an email under 254 chars?"
  └──────┬───────┘   ✗ fail → reject with a clear message
         │           ✓ pass
         ▼
  ┌──────────────┐   store the ORIGINAL, unescaped
  │  PERSIST     │   (escaping on input corrupts data and breaks
  └──────┬───────┘    the day you render it somewhere new)
         │
         ▼
  ┌──────────────┐   HTML? URL? SQL? shell? each escapes differently
  │  ESCAPE for  │   this is where injection is actually prevented
  │  the SINK    │
  └──────────────┘
diagram
VALIDATE vs SANITIZE — not interchangeable

  VALIDATE   accept or reject, unchanged      email, age, uuid, enum
             fail closed on anything unknown

  SANITIZE   accept and modify                rich text HTML only
             allowlist tags + attributes, drop everything else

  Use sanitization ONLY where markup is genuinely required.
  Everywhere else, validate and escape.
diagram
ALLOWLIST beats BLOCKLIST — always

  ✗ blocklist   strip "<script>"      ⇒ <ScRiPt>, <img onerror>, <svg onload>
                                        the bypass list is infinite

  ✓ allowlist   keep [b,i,em,strong,a,p,ul,li]
                keep attrs [href, title]
                drop everything else, including anything invented next year

How it works

  1. Validate on both sides. Client for feedback, server as the gate — the client's copy can be bypassed entirely.
  2. Validate by type, not by pattern-matching bad input: schema libraries (Zod, Yup, JSON Schema) reject anything that doesn't fit.
  3. Store the raw value. Escaping at input time means you escape twice when it's later rendered into a different context.
  4. Escape at the sink — HTML-escape for the DOM, URL-encode for query strings, parameterise for SQL, never build shell commands from user data.
  5. Normalise before validating (trim, Unicode NFC) so equivalent inputs don't slip through a length or uniqueness check.

Trade-offs

RuleWhy
Fail closedUnknown input is rejected, not "cleaned"
One schema, both sidesClient and server can't drift apart
Limit length everywhereCheapest defence against payload and ReDoS abuse
Sanitize only rich textEvery other field just needs escaping

Interview angle

"You sanitize on input. Why is that not enough?"

  • The safe form depends on the destination — the same string needs different treatment in HTML, a URL, and SQL.
  • Escaping early corrupts the stored data and double-escapes when rendered elsewhere.
  • Correct order: validate shape on input, store raw, escape at each output sink.

Recap

  • Validation rejects; sanitization modifies. Only rich text needs the second.
  • Allowlists survive attacker creativity; blocklists don't.
  • Escape at the sink, because the sink defines what "safe" means.