Token Placement and Session State

## The core difference: ambient versus explicit A cookie is **ambient authority**. After a `Set-Cookie`, the browser attaches it to any request matching its domain, path and attributes - whether that request came from your app, a link, a form on another site, or an image tag. Nothing in your code decides. An `Authorization` header is **explicit**. It exists only because your code put it there on that specific request. A cross-site form post carries no such header. Almost every practical difference follows from this one property. ## Cookies in detail *Attributes that matter*: `HttpOnly` hides the value from `document.cookie`, so XSS cannot simply read it - though script can still *use* the session by making requests, so it is mitigation, not immunity. `Secure` restricts it to HTTPS. `SameSite` controls cross-site attachment: `Strict` never sends on cross-site requests, `Lax` sends on top-level navigations only (so a cross-site GET navigation carries it but a cross-site POST does not), `None` sends always and requires `Secure`. `Domain` and `Path` scope it. *CSRF*: an attacker page issues a POST to your transfer endpoint from a hidden form. The browser attaches the cookie, and the server sees an authenticated request it cannot distinguish from a legitimate one. Defences: `SameSite=Lax`, which removes the common case; a synchroniser or double-submit anti-CSRF token that the attacker cannot read because of the same-origin policy; and checking `Origin` or `Sec-Fetch-Site` on state-changing requests. Note that `SameSite` is a browser behaviour, not a substitute for a server-side check in high-value flows. *Cross-origin*: sending cookies to a different origin requires CORS with credentials included on the client and, on the server, `Access-Control-Allow-Credentials: true` with a specific - never wildcard - `Access-Control-Allow-Origin`. *Fit*: first-party browser apps, especially server-rendered ones, where the same site serves pages and API. ## Bearer headers in detail `Authorization: Bearer <token>` is the standard scheme for tokens: `Authorization` is a core HTTP header, and the Bearer scheme is widely used beyond its OAuth origins. *Security profile*: no ambient attachment, so classic CSRF does not apply. But the token must be stored client-side. Web storage is readable by any script on the origin, so an XSS payload can exfiltrate it and use it from anywhere until it expires - which is worse than XSS against an `HttpOnly` cookie, where the attacker can only act from the victim's browser. Keeping the token in memory only is safer but is lost on page reload. *Ergonomics*: works identically for mobile apps, server-to-server calls, CLI tools and cross-origin browser calls, with no cookie-domain constraints. The client owns refresh, expiry and retry-on-401 logic. *Hygiene*: never put a token in a URL query string - URLs land in server logs, browser history, `Referer` headers and analytics. Always use HTTPS; a Bearer token is a bearer instrument, valuable to whoever holds it. ## A common hybrid Browser apps frequently combine both: a short-lived access token used as a Bearer header for API calls, and the long-lived refresh token in an `HttpOnly; Secure; SameSite` cookie scoped to the refresh endpoint alone. The valuable long-lived credential is unreadable by script; the short-lived one carries little value if stolen; and only the refresh endpoint, which performs no business action, needs CSRF consideration. ## Relationship to statelessness Placement is orthogonal to whether the server holds a session. A cookie can carry a self-contained signed token, and a Bearer header can carry an opaque id the server looks up. Do not conflate cookie with stateful: where the credential travels is a separate question from what it references. ## Answering well Lead with ambient versus explicit, derive CSRF from it, name the mitigating attributes, then present the XSS trade honestly in both directions, and finish with the hybrid and the note that placement does not imply server-side session storage.