EXERCISE 3 — Encoding vs sanitization: pick the right tool
===========================================================

THE DISTINCTION:
  - ENCODING: transforms data so it displays LITERALLY as text; no markup the
    user supplied is functional. Use when the value should be SHOWN AS TEXT.
  - SANITIZATION: parses HTML and REMOVES dangerous parts while KEEPING an
    allowlisted subset of safe markup functional. Use when the value is meant
    to BE HTML (rich text).
  Default to ENCODING; reach for SANITIZATION only when you must render
  user-provided HTML.

(a) Display a user's chosen display-name.
    USE: ENCODING (HTML entity / attribute, per context).
    WHY: a display name is TEXT. It should never contain functional markup.
    Encoding shows whatever they typed literally and makes any <script> inert.
    If you SANITIZED instead, you'd be needlessly running an HTML parser on a
    plain string; if you did nothing, "<script>" in a name is stored XSS.

(b) Render a rich-text comment that allows <b> and <a>.
    USE: SANITIZATION (allowlist: e.g. DOMPurify configured to permit b, a,
    i, p, ... and safe href schemes).
    WHY: here the value is MEANT to be HTML -- the feature requires <b> to
    render bold and <a> to be a link. ENCODING would defeat the feature: it
    would print the literal text "<b>" instead of bold. Sanitization keeps the
    allowed tags working while stripping <script>, onX handlers, javascript:
    URLs, etc. (Even better where possible: accept Markdown and render it
    through a safe renderer -- Chapter 7.)

(c) Show a search query back to the user ("You searched for: ...").
    USE: ENCODING (HTML body / attribute, per context).
    WHY: the echoed query is TEXT to display, the classic REFLECTED-XSS spot
    (Chapter 2). Encoding renders the query literally and neutralises any
    payload. No markup should be functional here, so no sanitization needed.

WHY THE WRONG TOOL HURTS:
  - Using ENCODING where HTML is REQUIRED (case b): the feature breaks -- tags
    show up as visible text ("<b>bold</b>") instead of formatting. The common
    WRONG "fix" is to disable encoding and output raw -> instant XSS. The right
    move is to recognise it's an HTML-output need and SANITIZE.
  - Using SANITIZATION (or nothing) where TEXT is expected (cases a, c): at
    best unnecessary parsing overhead; at worst, a permissive/misconfigured
    sanitizer lets through something an encoder would have made trivially safe.
    For plain text, encoding is simpler, complete, and correct.

RULE OF THUMB:
  Ask: "Is this value TEXT or MARKUP?"
    TEXT   -> ENCODE (default).
    MARKUP -> SANITIZE with a strict allowlist (or use Markdown).
  Never disable encoding to make tags render -- that's the signal to switch to
  sanitization, not to drop the defence.