Session Hijacking: Token Theft, Fixation, and Cookie Protections

HTTP has no memory. Every request is independent, so applications issue a session identifier after login and the browser presents it with each subsequent request. That identifier is the authentication for the rest of the session — anyone holding it is the user, and no password is required. Session hijacking is simply obtaining someone else's.

How tokens are stolen

Cross-site scripting is the most common route. Injected JavaScript running in the victim's page can read cookies and send them anywhere, and because the script runs inside the site's own origin, nothing about it looks abnormal to the browser.

Network interception works wherever a session travels unencrypted, which today usually means a mixed-content page or an application that redirects to HTTPS but has already exposed the cookie on the initial plaintext request.

Malware on the endpoint reads tokens straight from browser storage, which is why stolen-cookie marketplaces exist and why a user who has been infected needs their sessions invalidated, not just a password reset.

Predictable identifiers are a design failure rather than an attack: a session ID derived from a counter, a timestamp, or a weak generator can be guessed. Identifiers must come from a cryptographically secure random source with enough length to make searching hopeless.

Referrer and logging leakage catches applications that put the session identifier in the URL, where it ends up in browser history, server logs, proxy logs, and the Referer header sent to third-party sites.

Fixation is the opposite direction

In session fixation the attacker does not steal a token — they supply one. The victim is led to the site with a session identifier the attacker already knows, and if the application keeps that identifier after the user authenticates, the attacker's known token is now an authenticated session.

The fix is one line of behavior: regenerate the session identifier on every privilege change, above all at login. Any pre-authentication token becomes worthless the moment it is replaced.

Cookie protections

Most of the defense is in how the cookie is issued.

The HttpOnly flag makes the cookie unreadable to JavaScript, which is what stops cross-site scripting from lifting it. The Secure flag means the cookie is only ever sent over HTTPS, closing the plaintext exposure. SameSite controls whether the cookie accompanies cross-site requests, with Lax as a sensible default and Strict where the application can tolerate it — this also removes most cross-site request forgery exposure.

Scope the cookie tightly with correct domain and path attributes so it is not shared with subdomains that do not need it, and use the __Host- prefix where supported to bind it to the exact origin.

Server-side, set an absolute session lifetime as well as an idle timeout, invalidate the session properly on logout rather than only clearing the client cookie, and give users a way to see and revoke their active sessions. Rotating the identifier periodically during a long session limits the value of a token captured early.

Detection and binding

Binding a session loosely to its context catches reuse. A session whose requests suddenly arrive from a different network or a different browser fingerprint is suspicious — bind loosely, because strict binding to an IP address breaks mobile users moving between networks, and the usual outcome is that someone disables the check entirely.

Concurrent use of one session from two distant locations is the clearest signal, and it is the same reasoning as impossible travel applied to sessions rather than logins. Re-authenticate before genuinely sensitive actions — changing a password, adding a payment method — so a hijacked session cannot complete them.

A WAF helps at the edge by blocking common injection payloads and by flagging anomalous session behavior, though it is a filter in front of the application rather than a substitute for issuing cookies correctly.

Tokens beyond cookies

The same problem exists for bearer tokens issued by modern authorization flows. A bearer token is, by definition, usable by whoever holds it, so short lifetimes, refresh token rotation, and audience restriction are what limit the damage. Sender-constrained tokens, bound to a client key, remove the bearer property entirely and are the direction the standards are moving — worth knowing alongside the federation protocols that issue them.

Exam angles

Know that a session identifier substitutes for credentials and that holding it is sufficient to impersonate the user. Distinguish theft from fixation, and know that regenerating the identifier at login is the fix for fixation. Name HttpOnly, Secure, and SameSite and state what each prevents. Recognize cross-site scripting as the leading theft vector, and expect a scenario where the correct answer is invalidating active sessions rather than only resetting a password.