EXERCISE 2 — How the 2020 default flip reduced CSRF automatically
=================================================================

WHAT CHANGED:
  - BEFORE: a cookie with NO explicit SameSite attribute was treated as
    SameSite=None -- i.e. sent on ALL requests, including every cross-site
    request. This is the behaviour classic CSRF relied on.
  - 2020: Chrome (followed by other major browsers) changed the default for
    cookies WITHOUT an explicit SameSite to SameSite=Lax.

WHY THAT REDUCED CSRF RISK WITHOUT DEVELOPER ACTION:
  - The most common CSRF vector is a cross-site auto-submitting POST form
    (Chapter 3). Under the new Lax default, the browser stops attaching the
    session cookie to cross-site POSTs automatically.
  - So for the huge number of apps that NEVER set SameSite at all, their
    session cookies silently became Lax, and the classic POST-form CSRF
    stopped working against them -- with zero code changes, across most of
    the web, essentially overnight.
  - Net effect: the baseline CSRF exposure of the entire web dropped
    dramatically. CSRF went from "exploitable by default" to "blocked by
    default for the common case."

WHY YOU SHOULD STILL SET SameSite EXPLICITLY AND STILL USE TOKENS:

  Reason 1 -- the default is not universal or guaranteed.
    - Older browsers don't apply the Lax default. Some clients/edge cases
      differ. Relying on an implicit default means relying on every visitor's
      browser behaving the modern way. Setting SameSite=Lax explicitly makes
      the intent unambiguous and consistent.

  Reason 2 -- Lax leaves real gaps that tokens cover.
    - State-changing GET endpoints (Lax sends cookies on top-level GET
      navigations), the historical "Lax+POST" 2-minute grace window,
      SameSite=None cookies that need cross-site use, and the site-vs-origin
      gap (sibling subdomains are "same-site") are all NOT covered by Lax.
    - Anti-CSRF tokens (Chapters 5-6) defend these because they require a
      secret in the request regardless of cookie-sending rules.

  (Bonus reasons: explicit config documents your security posture; and
  defense in depth means one mechanism failing/misconfigured doesn't expose
  you.)

CONCLUSION:
  The default flip made CSRF much less dangerous by default, but it's a
  baseline, not a complete defence. Set SameSite explicitly AND keep tokens
  -- belt and braces (Chapter 8).