Sessions & Tokens
How the server keeps remembering you: session IDs, cookie attributes, hijacking, rotation, revocation, and what JWTs actually buy and cost.
Every lesson below identifies the asset, attacker capability and boundary before naming the vulnerability. Controls are split into prevention, detection and recovery; residual risk is explicit.
Authentication happens once; the session is what makes the next thousand requests work — a random opaque identifier that maps to server-side state you can inspect, expire and revoke.
Six attributes decide whether a cookie is a reasonable place to keep a session or a liability: `Secure`, `HttpOnly`, `SameSite`, `Domain`, `Path` and lifetime — and each one maps to a specific attack.
The attacker does not need the password: possession of the session token is possession of the account, and every defense is either about preventing the token from escaping or about limiting what it is worth once it has.
A signed, self-contained token that lets a service verify a claim without a lookup — which buys statelessness and pays for it with revocation you have to engineer separately.
The specific ways token validation goes wrong — trusting the header's algorithm, skipping issuer and audience, over-long expiry, treating signed as confidential — and the verification routine that closes all of them.