EXERCISE 1 — Does classic CSRF apply? (the auto-sent test)
==========================================================

THE TEST: "Is the auth credential attached AUTOMATICALLY by the browser on a
cross-site request?" If yes -> classic CSRF applies. If the credential must
be added explicitly by JS (or there's no browser) -> classic CSRF does not.

(a) Auth via Authorization: Bearer header, from JS memory.
    CSRF APPLIES? NO.
    The browser does NOT auto-attach Authorization headers. The token lives
    in JS memory and must be added explicitly per request. A forged cross-
    site request (form/img/simple fetch) cannot include it -- the attacker
    can't read the token (SOP) and the browser won't add it. No classic CSRF.
    (Watch XSS instead: same-origin script CAN read the token.)

(b) Auth via a session cookie.
    CSRF APPLIES? YES.
    The browser auto-attaches the cookie to every request to the domain,
    including forged cross-site ones (ambient authority). Classic CSRF
    exposure -> needs SameSite + anti-CSRF tokens.

(c) Auth via a JWT stored in a cookie.
    CSRF APPLIES? YES.
    Storage is what matters, not the token format. A JWT in a cookie is
    auto-sent exactly like a session cookie -> full classic CSRF exposure ->
    needs SameSite + tokens. ("We use JWT" does NOT make it safe.)

(d) Native mobile app sending a token header.
    CSRF APPLIES? NO.
    There's no browser and no ambient cookie-attachment behaviour driving the
    request from a malicious web page. The app adds its token explicitly.
    Classic CSRF (which is a browser phenomenon) doesn't apply. Use normal
    token auth + transport security.

SUMMARY:
  (a) header bearer token .. NO   (not auto-sent)
  (b) session cookie ....... YES  (auto-sent)
  (c) JWT in a cookie ...... YES  (auto-sent -- storage decides)
  (d) mobile token header .. NO   (no browser/ambient cookies)

The single discriminator every time: AUTO-SENT BY THE BROWSER? Cookies yes;
explicit headers and non-browser clients no.