EXERCISE 2 — CSP nonces: allow yours, block theirs
===================================================

HOW A NONCE WORKS:
  - On EACH response, the server generates a fresh random value (the nonce)
    and does two things:
      1. Puts it in the CSP header:   script-src 'nonce-r4nd0m123'
      2. Puts it on every TRUSTED inline script:  <script nonce="r4nd0m123">
  - The browser executes an inline script ONLY if its nonce attribute matches
    the nonce in the header. Scripts without the matching nonce are blocked.

WHY YOUR SCRIPTS RUN BUT THE ATTACKER'S DOESN'T:
  - YOUR inline scripts are emitted by the server, which stamps them with the
    current nonce -> they match the header -> they execute.
  - The ATTACKER'S injected inline script is inserted via the XSS hole, NOT by
    your server's templating, so it has no nonce (or a wrong/guessed one):
        <script>steal()</script>            -> no nonce -> BLOCKED
        <script nonce="guess">steal()</script> -> wrong nonce -> BLOCKED
  - The attacker would need to know the correct nonce to add it. They can't,
    because (see below) it's random and changes every response. So injected
    inline scripts are blocked while your stamped ones run.

WHY THE NONCE MUST BE RANDOM AND PER-RESPONSE:
  - RANDOM (cryptographically): if it were predictable, the attacker could
    compute it and add a matching nonce= to their injected script, defeating
    the check. Unpredictability is the whole security property.
  - PER-RESPONSE (fresh each time): if the same nonce were reused across
    responses, an attacker who observed it once (e.g. in a cached page, a
    stored reflection, or another user's response) could reuse that value in
    an injected script. Regenerating per response means a nonce seen in one
    response is useless for any other. (Also why nonces must NOT be placed in
    cacheable/static HTML.)
  - Together: random + per-response = the attacker can neither guess nor
    replay it, so they can never present a valid nonce.

WHY 'unsafe-inline' DESTROYS THE PROTECTION:
  - 'unsafe-inline' tells the browser to allow ALL inline scripts
    unconditionally -- no nonce/hash required.
  - That re-permits exactly the attacker's injected inline <script> and onX
    handlers. The nonce mechanism becomes irrelevant: everything inline runs,
    including the payload.
  - So  script-src 'self' 'unsafe-inline'  (or adding 'unsafe-inline' alongside
    a nonce in older browsers that don't ignore it) provides ~zero XSS
    protection. NOTE: in CSP Level 2+, if a nonce or hash is present, modern
    browsers IGNORE 'unsafe-inline' -- a backward-compat safety valve -- but
    you should still not rely on 'unsafe-inline'; use nonces/hashes and omit
    it. The point of CSP-for-XSS is precisely to forbid arbitrary inline
    script; 'unsafe-inline' un-forbids it.

ONE-LINE TAKEAWAY:
  A per-response random nonce lets the SERVER mark which inline scripts are
  trusted; the attacker can't forge that mark -- unless you neutralise the
  whole scheme with 'unsafe-inline'.