EXERCISE 2 — Key security headers, what they do, and why "missing" = misconfig
===============================================================================

THE KEY SECURITY HEADERS:

  1. Strict-Transport-Security (HSTS)
     e.g. Strict-Transport-Security: max-age=31536000; includeSubDomains
     DOES: tells the browser to ONLY use HTTPS for this site for max-age
     seconds — it auto-upgrades and refuses plain HTTP, closing the
     SSL-stripping first-hop gap.
     RELATES TO: the HTTPS course (HSTS chapter) — defends against
     downgrade/SSL-stripping man-in-the-middle.

  2. Content-Security-Policy (CSP)
     e.g. Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'
     DOES: restricts where scripts/styles/etc. may load and execute from, so an
     injected inline <script> won't run (with a nonce/hash, no 'unsafe-inline').
     RELATES TO: the XSS course — a browser-enforced backstop that limits XSS
     blast radius if encoding/sanitization fail.

  3. X-Content-Type-Options: nosniff
     DOES: stops the browser from MIME-SNIFFING (guessing a response's type and
     overriding the declared Content-Type). Prevents tricks where a file is
     served as one type but interpreted as another (e.g. a "text" upload run as
     script/HTML).
     RELATES TO: XSS / content-injection — closes a sniffing-based execution
     vector.

  4. X-Frame-Options: DENY  (modern: CSP frame-ancestors 'self')
     DOES: controls whether your pages may be embedded in <iframe>s on other
     sites — prevents CLICKJACKING (UI redress, where your page is framed
     invisibly over a decoy).
     RELATES TO: clickjacking (a UI-layer attack); frame-ancestors is the
     CSP-based successor.

  5. Referrer-Policy: strict-origin-when-cross-origin
     DOES: limits how much of the referring URL is sent in the Referer header to
     other sites — prevents leaking sensitive path/query data (tokens, ids) via
     referrers.
     RELATES TO: information disclosure / privacy (and avoids leaking secrets in
     URLs — related to the HTTPS/Auth concerns about tokens in URLs).

  (Also worth setting: Permissions-Policy to disable unneeded browser features;
   and a correct Set-Cookie with HttpOnly; Secure; SameSite — Auth/CSRF.)

WHY "MISSING HEADERS" IS A MISCONFIGURATION, NOT A CODE BUG:
  - These protections are turned on by emitting the right HTTP RESPONSE HEADERS
    — a CONFIGURATION concern (web server config, a middleware setting, a
    reverse-proxy rule), not application logic. The app's code can be entirely
    correct while the deployment simply never sets them.
  - The vulnerability is the ABSENCE OF A HARDENING STEP in how the system is
    set up/deployed: the secure state (headers present and correct) wasn't
    configured. That's the definition of A05 — a secure app left in a less-safe
    state by its configuration.
  - It's also low-effort, high-value (usually a few lines of config/middleware),
    and easy to verify with tools (securityheaders.com, Mozilla Observatory).
    Being a config toggle is exactly why forgetting it is "misconfiguration"
    rather than a coding defect — and why it should be part of a repeatable,
    automated hardened configuration (Exercise 3).

ONE-LINE TAKEAWAY:
  HSTS (HTTPS), CSP (XSS), nosniff (MIME-sniffing), frame-ancestors/X-Frame-
  Options (clickjacking), Referrer-Policy (info leak) are cheap browser-side
  protections switched on by config — missing them is an A05 hardening omission,
  not a code bug.