EXERCISE 2 — The session cookie's security flags
=================================================

THE COMPLETE Set-Cookie:
  Set-Cookie: __Host-sessionId=9f8c...; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

(Using the __Host- prefix forces Secure + Path=/ + no Domain. If you can't
use the prefix, at minimum set HttpOnly; Secure; SameSite.)

FLAG-BY-FLAG — what it blocks and which course it comes from:

  HttpOnly
    EFFECT: the cookie is not readable by JavaScript (document.cookie won't
    include it).
    BLOCKS: XSS exfiltrating the session id via document.cookie.
    FROM: the XSS course.

  Secure
    EFFECT: the browser only sends the cookie over HTTPS, never plain HTTP.
    BLOCKS: a network attacker sniffing the session id off a plaintext
    connection (and SSL-stripping a later request).
    FROM: the HTTPS/TLS course (pair with HTTPS-everywhere + HSTS).

  SameSite=Lax (or Strict)
    EFFECT: the cookie is not sent on (most) cross-site requests.
    BLOCKS: CSRF — a forged cross-site request arrives WITHOUT the session
    cookie, so it isn't authenticated.
    FROM: the CSRF course.

  __Host- prefix
    EFFECT: requires Secure, Path=/, and forbids a Domain attribute (so it
    can't be scoped to a parent domain).
    BLOCKS: cookie injection / overwrite from a sibling or subdomain.
    FROM: CSRF course (double-submit pitfall) + general hardening.

  (Plus Max-Age / Expires for lifetime — see Exercise 3 timeouts.)

WHY HttpOnly ALONE DOESN'T MAKE XSS HARMLESS:
  - HttpOnly stops a script from READING the session cookie value, defeating
    cookie THEFT. But it does NOT stop the script from ACTING within the
    session: an injected script makes same-origin requests, and the browser
    AUTOMATICALLY attaches the HttpOnly cookie to them. So the script can
    change the email, transfer funds, read data — "riding" the session — all
    without ever seeing the cookie (XSS course, "session riding"). It can also
    read the anti-CSRF token from the page. So HttpOnly is a valuable
    mitigation, but the real fix is to PREVENT XSS (output encoding,
    sanitization, CSP). "Fix XSS first."

WHY SameSite ALONE DOESN'T FULLY REPLACE CSRF TOKENS:
  - SameSite=Lax still SENDS the cookie on top-level GET navigations, so a
    state-changing GET endpoint remains forgeable; the historical Lax+POST
    grace window and old browsers leave gaps; and SameSite keys on SITE, not
    origin, so a SAME-SITE sibling subdomain (a.example.com -> b.example.com)
    is not blocked. So SameSite is a strong baseline but incomplete — keep
    anti-CSRF tokens and never change state on GET (CSRF course Ch.7-8).

TAKEAWAY:
  These four attributes encode the whole quartet (Secure=HTTPS, HttpOnly=XSS,
  SameSite=CSRF, on the session cookie this course protects). Set them ALL —
  but treat each as one layer, not a complete defence, and keep the
  application-level defences (XSS prevention, CSRF tokens) alongside them.