Session Hijacking: How It Works and How to Stop It

Session hijacking is when an attacker takes over a user’s logged-in session by stealing or guessing the token that proves who they are. Once they hold that token, the website treats them as the real user, with no password and no MFA prompt needed. For a business, that can mean someone reading email, moving money or changing settings under a staff member’s name.

This guide explains how session hijacking works, the main ways attackers pull it off, and the fixes that matter most. It is written for IT managers and business owners, not specialists.

What is session hijacking?

When you log in to a website, the server creates a session. It hands your browser a session ID, usually stored in a cookie, and your browser sends that ID back with every request. The server uses it to remember that you are you.

That ID works like a wristband at a festival. Staff do not ask who you are every time you walk through a gate. They just check the band. If someone copies or steals your band, they get your access.

OWASP, the web security community, puts it plainly: “The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking.” In other words, the attack is about the token, not the password.

How does session hijacking work?

Every attack follows the same three steps. The user logs in and gets a valid session. The attacker obtains the session ID by some route. Then the attacker sends that ID to the site from their own device and carries on as the user.

Because the session is already authenticated, the login page never gets involved. That is why session hijacking is often called a post-login attack, and why it can slip past controls that only protect the front door.

What are the main types of session hijacking?

There are several routes to a stolen token. Most real incidents use one of the five below.

Session sniffing

If a site sends session cookies over plain HTTP, anyone on the same network can capture them. Public Wi-Fi is the classic case. Modern sites use HTTPS, but a single page or subdomain served without it can still leak a cookie.

Cross-site scripting (XSS)

If an attacker can run their own JavaScript in your site, that script can read the session cookie and send it elsewhere. OWASP notes that injected script can expose the token in exactly this way. Our guide to cross-site scripting covers how these flaws appear in the first place.

Session fixation

Here the attacker does not steal the ID. They plant one. They trick the victim into using a session ID the attacker already knows, then wait for the victim to log in. If the site keeps the same ID after login, the attacker is now in too. OWASP’s guidance is blunt: web applications “should never accept a session ID they have never generated.”

Predictable session IDs

Weak code can produce IDs that follow a pattern, such as a counter or a timestamp. An attacker who works out the pattern can guess valid IDs without stealing anything. OWASP says IDs need at least 64 bits of entropy, generated with a cryptographically secure random number generator.

Malware and man-in-the-middle attacks

Infostealer malware on a laptop can lift session cookies straight out of the browser. Attackers can also sit between a user and a site with a proxy, relay the real login and MFA prompt, and keep the resulting token. OWASP lists man-in-the-middle and man-in-the-browser attacks among the known methods.

Does MFA stop session hijacking?

Not on its own. MFA protects the moment of login. A stolen session token is proof that login already happened, so the attacker skips that step entirely.

That does not make MFA pointless, because it still blocks the huge volume of password-only attacks. Our article on what MFA stops and what still gets through goes into the gaps. The practical lesson is that you need to protect the session as well as the login.

What does session hijacking look like to the victim?

Often it looks like nothing. The user keeps working and sees no alert, so the signs tend to appear on the server side instead:

• One session ID used from two different countries within minutes.
• A sudden change of browser or device details mid-session.
• Mailbox rules, forwarding addresses or payment details changed without a matching login event.
• Users reporting they were logged out for no reason.

OWASP recommends logging session lifecycle events, such as creation, renewal and destruction, and watching for reused IDs or unexpected IP and User-Agent changes. It also advises logging a salted hash of the ID rather than the raw value, so your logs do not become a source of stolen tokens.

How do you prevent session hijacking?

Most of the defence sits in how the application is built. If you run a web application, put these in front of your developers.

Lock down the cookie

Three attributes do a lot of work. MDN explains that a cookie with Secure is only sent over HTTPS, one with HttpOnly cannot be read by JavaScript, and SameSite limits when a cookie travels with cross-site requests. OWASP recommends SameSite=Strict where you can, or Lax at minimum, and the __Host- prefix for session cookies.

A well-formed session cookie might look like this:

Set-Cookie: __Host-SessionID=<value>; Secure; HttpOnly; SameSite=Strict; Path=/

Regenerate the ID at login

Issue a fresh session ID whenever a user logs in or changes privilege, and destroy the old one. MDN gives the same advice: regenerate and resend session cookies whenever a user authenticates. This single step defeats session fixation.

Set sensible timeouts

Short sessions give a stolen token less time to be useful, so they are worth the small annoyance. OWASP suggests idle timeouts of 2 to 5 minutes for high-value applications and 15 to 30 minutes for low-risk ones, plus an absolute limit such as 4 to 8 hours. Enforce both on the server, because a timer in the browser can be tampered with.

Make logout real

Clicking logout should invalidate the session on the server. Clearing the cookie in the browser is not enough, because a copied ID would still work. Require re-authentication before high-risk actions such as changing a password or email address.

Keep tokens out of URLs and caches

Session IDs in a web address end up in browser history, logs and referrer headers. Use cookies only, and send Cache-Control: no-store on responses that carry session data.

Protect the endpoint too

Application fixes only go so far, because malware on a laptop can still read the browser’s cookie store. So keep devices patched, use endpoint protection, and limit browser extensions. Newer approaches that bind a session to a specific device are starting to appear as well, and they are worth watching.

How can you test whether your application is vulnerable?

A scanner will catch missing cookie flags, but it will not tell you whether your session logic holds up against a determined person. A tester will check things like whether the ID changes at login, whether logout really kills the session, whether tokens can be guessed, and whether XSS anywhere on the site hands over cookies.

That is a standard part of a web application penetration test. If you would like a second pair of eyes on how your application handles sessions, you can get in touch with our team to scope one.

Frequently asked questions

Is session hijacking the same as session fixation?

No. Hijacking is the umbrella term for taking over a session. Fixation is one method, where the attacker sets the session ID before the victim logs in instead of stealing it afterwards.

Is session hijacking illegal in the UK?

Yes. Accessing someone else’s account without permission is an offence under the Computer Misuse Act 1990. Authorised testing, with a signed scope, is the lawful way to check your own defences.

Can HTTPS alone prevent session hijacking?

It stops sniffing on the network, which is a big win. It does nothing against XSS, malware, fixation or weak session IDs, so you still need the other controls.

What is the difference between session hijacking and a man-in-the-middle attack?

A man-in-the-middle attack describes where the attacker sits, between user and server. Session hijacking describes what they take. Intercepting traffic is one way to steal a session token, but not the only way.

How do I know if my accounts have been hijacked?

Look for logins or activity from unfamiliar locations, changed account settings and unexplained mailbox rules. Then end all active sessions, reset the password and review recent changes.