EXERCISE 3 — Walking the decision flow for three features
==========================================================

THE FLOW:
  1. Needs to render as HTML? No -> ENCODE (done).
  2. Yes -> can you use Markdown/structured format instead of raw HTML? Prefer it.
  3. Must accept HTML -> SANITIZE (DOMPurify, narrow allowlist, kept updated).
  4. Independently -> VALIDATE strict-format fields; layer CSP under everything.

(a) A username shown on a profile.
    VALUE TYPE: TEXT (a name is not markup).
    DECISION: ENCODE on output (HTML body / attribute per context).
    WHY: it should display literally; never render tags. No HTML needed, so
    step 1 short-circuits to encoding. <script> in a name becomes inert text.
    OPTIONAL: light validation (max length, maybe disallow control chars) for
    data quality -- but NOT as the XSS defence (names contain ' " < >, Ex.2).

(b) A blog post body with rich formatting.
    VALUE TYPE: MARKUP (it must render bold, links, lists, headings).
    DECISION: step 1 = yes (needs HTML). Step 2: PREFER MARKDOWN -- author in
    Markdown, render with a safe renderer that disables raw HTML. If raw HTML
    must be accepted (e.g. a legacy CMS), step 3: SANITIZE with DOMPurify using
    the narrowest allowlist the feature needs (headings, b, i, a[href], ul, li,
    img[src] with URL checks, ...), kept updated.
    WHY: you CAN'T encode (that would show tags as text and kill formatting),
    and you can't trust it raw (payloads). Sanitization/Markdown is the only
    safe way to render user HTML. Plus CSP underneath (step 4).

(c) An account-balance number.
    VALUE TYPE: STRICT FORMAT (a number) -- and typically server-controlled.
    DECISION: VALIDATE/normalise it's numeric, and ENCODE on output anyway.
    WHY: a balance has a narrow format, so allowlist-validate it as a number
    (reject anything non-numeric). Even though it's app-generated, still encode
    on output as defence in depth (data can come from unexpected places, and
    encoding a number is harmless). No HTML, no sanitization.

SUMMARY:
  feature              value is...     primary handling
  -------              ----------      ----------------
  (a) username         TEXT            ENCODE (output)  [+ optional validation]
  (b) blog post body   MARKUP          MARKDOWN or SANITIZE (DOMPurify) [+ CSP]
  (c) account balance  STRICT FORMAT   VALIDATE (numeric) + ENCODE

PRINCIPLE:
  Classify by what the value IS:
    TEXT          -> ENCODE
    MARKUP        -> SANITIZE (or use a safe restricted format like Markdown)
    STRICT FORMAT -> VALIDATE (allowlist) + ENCODE on output
  And put CSP (Chapter 8) under all of them as a safety net.