EXERCISE 2 — Auditing an app against the broken-defence catalogue
=================================================================

THE APP DOES:
  (i)   strips "<script>" from input
  (ii)  HTML-encodes all output
  (iii) sets a CSP with 'unsafe-inline'
  (iv)  renders comments with v-html

FLAW (i) -- Blocklist filtering ("strip <script>").
  WHY IT FAILS: blocklists have infinite bypasses (Chapter 4): case variants
    (<ScRiPt>), no-script vectors (<img src=x onerror=...>, <svg onload=...>),
    entity/whitespace tricks, broken-up keywords. Stripping the literal
    "<script>" blocks almost nothing.
  ALSO: filtering at INPUT corrupts legitimate data and isn't the defence.
  FIX: remove the blocklist; rely on context-aware OUTPUT ENCODING (and
    sanitization for HTML). Don't try to detect bad input.

FLAW (ii) -- HTML-encoding ALL output (one encoder for every context).
  WHY IT FAILS: encoding must MATCH THE CONTEXT (Chapter 3/6). HTML-entity
    encoding is correct for HTML body, but does NOT protect values placed in:
      * JavaScript contexts (</script> / quote breakouts; JS ignores entities)
      * URL contexts (javascript: scheme has no HTML-special chars)
      * unquoted attributes (whitespace breakout)
    So "HTML-encode everywhere" leaves those contexts exploitable.
  FIX: use CONTEXT-AWARE encoding -- HTML-body, attribute (quoted), JS-string,
    URL (scheme allowlist + encode), CSS -- ideally via the framework's
    context-aware auto-escaping rather than one blanket encoder.

FLAW (iii) -- CSP with 'unsafe-inline'.
  WHY IT FAILS: 'unsafe-inline' re-allows ALL inline scripts/handlers --
    including injected ones -- so the CSP provides ~zero XSS protection
    (Chapter 8). It looks like a defence but isn't.
  FIX: remove 'unsafe-inline'; use a NONCE- or HASH-based script-src; move
    inline scripts to external files or stamp them with the per-response
    nonce; roll out via Content-Security-Policy-Report-Only first; consider
    Trusted Types (require-trusted-types-for 'script').

FLAW (iv) -- Rendering comments with v-html (unsanitized).
  WHY IT FAILS: v-html bypasses Vue's auto-escaping and sets innerHTML to the
    raw comment -> stored XSS for every viewer (Chapter 9). This is the actual
    live hole; comments are attacker-controlled.
  FIX: sanitize before rendering -- v-html="DOMPurify.sanitize(comment)" with a
    narrow allowlist -- or, better, render comments as TEXT ({{ comment }}) if
    they don't need HTML, or accept Markdown rendered safely.

PRIORITY:
  The v-html stored XSS (iv) is the most urgent (live, affects all viewers).
  The 'unsafe-inline' CSP (iii) means there's no backstop if anything slips.
  The encoding gap (ii) is a latent hole in JS/URL contexts. The blocklist (i)
  gives false confidence and should be replaced, not patched.

CORRECTED POSTURE:
  Context-aware output encoding (framework auto-escaping) + DOMPurify for the
  comment HTML + strict nonce-based CSP (no 'unsafe-inline') + URL-scheme
  allowlisting + drop the input blocklist. Layer them; encoding/sanitization
  are the foundation, CSP the backstop.