EXERCISE 2 — Why input validation can't be the primary XSS defence
===================================================================

WHY VALIDATION CAN'T BE PRIMARY (free-text fields legitimately contain
HTML-special characters):

  Field 1 -- a NAME.
    Legitimate value: O'Brien, "Bob" <the boss>, AT&T, Müller-Lévy.
    Names genuinely contain ' " < > &. If you reject those characters you
    break real users' names. So you must ACCEPT them -- and then neutralise
    them at output (encode), not reject them at input.

  Field 2 -- a COMMENT / MESSAGE / BUG REPORT.
    Legitimate value: "use a < b to compare" or "the form posts to
    <https://x>" or pasted code: if (a < b && c > d) { ... }.
    Free text routinely includes < > & " '. Rejecting them mangles ordinary
    content (math, code, quotes). Must accept; must encode on output.

  Field 3 -- a SEARCH QUERY.
    Legitimate value: users search for "<div>", "a && b", "price > 100".
    You can't forbid these characters or the search feature is crippled. The
    echoed query (reflected context) must be ENCODED on output instead.

  In all three, the dangerous characters are ALSO valid content, so there's no
  input filter that removes the threat without removing legitimate data. The
  only reliable fix is at OUTPUT (encode/sanitize), which makes the data safe
  regardless of what was entered. Hence validation is secondary
  (defence-in-depth), not the XSS defence.

TWO FIELDS WHERE ALLOWLIST VALIDATION GENUINELY HELPS:

  Field A -- a DATE (or UUID, or integer, or enum/select value).
    These have a STRICT, NARROW FORMAT. A date must match YYYY-MM-DD; a UUID
    matches a fixed pattern; a quantity is digits; a status is one of a fixed
    set. You can ALLOWLIST-VALIDATE: reject anything that doesn't match the
    exact format. A payload like <img onerror=...> simply isn't a valid date,
    so it's rejected outright -- input validation legitimately blocks it.

  Field B -- an EMAIL ADDRESS / a numeric amount / a country code.
    Constrained formats again: validate against the expected shape and reject
    off-format input. <script> isn't a valid email/number/country code, so
    validation rejects it.

WHY THE DIFFERENCE IS THE FIELD'S FORMAT:
  - When a field has a KNOWN, RESTRICTED format, you can define exactly what's
    valid and reject everything else (allowlist validation) -- and dangerous
    payloads don't fit the format, so they're excluded as a side effect.
  - When a field is FREE TEXT, "valid" includes the very characters payloads
    use, so no format-based rejection can separate safe from malicious. There,
    output encoding/sanitization is the only correct defence.
  - RULE: validate strict-format fields for data quality (and it helps
    security as a bonus); for free text, rely on output encoding/sanitization.
    Never claim "we validate input" as your XSS defence for free-text fields.