Sessions, Cookies & Stolen Tokens
Sessions are the mechanism that lets a server remember a logged-in user across later HTTP requests, usually by accepting a browser-sent cookie or token as evidence of an existing login. If that token is stolen, the attacker can often act as the user without knowing the password, passing MFA, or using the passkey.
HTTP requests are independent, so a server needs some way to connect “this request” with “the user who logged in earlier”. Repeating the full login ceremony on every click would be unusable and expensive. Instead, successful login creates a shorter-lived credential for the ongoing session. The security problem is that this credential becomes the thing the application trusts after login, not the original password, MFA challenge, or passkey assertion.
Concretely, the server sends a session identifier to the browser, commonly in a Set-Cookie response header. On later requests to matching paths and domains, the browser attaches it in the Cookie header. The server looks up or verifies that value, finds the associated user and session state, and authorises the request. Other designs use bearer tokens in explicit headers, but the core property is the same: possession of the token is treated as proof of the session.
The trade-off is convenience versus bearer-token risk. A session cookie is deliberately easy for the browser to send, which means a copied value may be enough for another client to impersonate the user until expiry or revocation. MFA and passkeys are commonly misunderstood here: they harden login, but normally do not protect every authenticated request. Defences such as HttpOnly, Secure, SameSite, rotation, reauthentication, device binding, logout invalidation, and server-side revocation reduce risk but do not make theft irrelevant.
Engineers meet this in browser developer tools, proxies, access logs, incident reports, and authentication middleware. After logging in, inspect a normal authenticated request and look for the Cookie header or an Authorization-style token-bearing header. That is the credential carrying the session. In practice, bugs arise when tokens leak through logs, browser extensions, XSS, misplaced cross-site settings, overly broad cookie scope, weak logout semantics, or session stores that cannot revoke compromised tokens quickly.
Common questions
- Why can a stolen session cookie bypass MFA or passkeys?
- Because the site usually checks MFA or a passkey during login, then issues a session credential for later requests. Once the attacker has that credential, their request can look like an already-authenticated browser request. Unless the application adds extra checks, it may not ask for the original login factors again.
- Is the danger specific to cookies?
- No. Cookies are common because browsers store and attach them automatically, but the underlying risk is bearer authentication. Any token accepted because the client possesses it can be stolen and replayed if protections are weak. Header tokens, API keys, and some session identifiers can have the same failure mode.
- Do HttpOnly, Secure, and SameSite solve stolen-token attacks?
- They help with specific theft and misuse paths, but they are not a complete answer. HttpOnly reduces script access, Secure limits transmission to HTTPS, and SameSite changes when browsers attach cookies on cross-site requests. They do not help if the token is leaked from logs, malware, a proxy, server-side exposure, or another trusted component.
- What should happen when a user logs out?
- The server should invalidate the session, not merely ask the browser to delete a cookie. Browser deletion removes the client’s copy, but a stolen copy may still exist elsewhere. Robust logout and incident response require server-side revocation or an equivalent mechanism that makes the old token unusable.