Session Hijacking

In Turkish: Oturum Ele Geçirme

Updated September 30, 20263 min read

In short

Session hijacking is an attack in which someone steals or guesses a user's session ID or token and uses it to act as that user without knowing their password.

What is session hijacking?

After you sign in, a website usually gives your browser a session ID in a cookie, or a token such as a JWT, so it doesn't have to ask for your password on every request. Whoever presents that value is treated as you. Session hijacking is the attack of obtaining that value and using it from the attacker's own browser, which skips the password and often multi-factor authentication entirely.

Attackers get session tokens in several ways: XSS scripts that read cookies not marked HttpOnly, malware on the victim's device that copies cookies out of the browser, sniffing unencrypted HTTP traffic on shared networks, tokens leaked in URLs or server logs, and weak, predictable session IDs that can be guessed. A related variant, session fixation, works the other way around: the attacker plants a known session ID in the victim's browser before they sign in, then uses it once the victim has authenticated.

Defenses include serving everything over HTTPS with HSTS, marking session cookies Secure, HttpOnly, and SameSite, generating long random session IDs, and issuing a new session ID at every sign-in and privilege change. Sessions should expire after inactivity and have an absolute lifetime, users should be able to see and revoke their active sessions, and sensitive actions such as changing an email address should require re-authentication. It is like someone copying the wristband you got at a festival entrance: the staff check the wristband, not your ticket, so the copy gets them in as you.

Session hijacking is often confused with CSRF. In CSRF, the attacker never sees the session token; they trick the victim's browser into sending a request that carries it automatically. In session hijacking, the attacker actually holds the token and can use it from anywhere, for as long as the session stays valid.

Key takeaways

Session hijacking steals a user's session ID or token to impersonate them.
Common sources are XSS, malware, unencrypted traffic, leaked URLs or logs, and predictable IDs.
Use Secure, HttpOnly, and SameSite cookies, HTTPS, and long random IDs.
Issue a new session ID at sign-in to prevent session fixation.
Expire sessions, allow revocation, and require re-authentication for sensitive actions.

Example

A session cookie that is hard to steal or misusejavascript

import { randomBytes } from "node:crypto";

// A long, random session ID that cannot be guessed
const sessionId = randomBytes(32).toString("base64url");

res.cookie("sid", sessionId, {
  httpOnly: true,         // scripts, including injected XSS, cannot read it
  secure: true,           // only ever sent over HTTPS
  sameSite: "lax",        // not sent on most cross-site requests
  maxAge: 30 * 60 * 1000, // expires after 30 minutes
});

// After every successful sign-in, issue a brand-new session ID
// so an ID planted before sign-in (session fixation) becomes useless

Readers ask

What is the difference between session hijacking and session fixation?

In session hijacking, the attacker steals a session ID that the victim already has. In session fixation, the attacker gives the victim a session ID the attacker already knows before sign-in, which is why servers must issue a fresh ID after authentication.

Does two-factor authentication prevent session hijacking?

No. Two-factor authentication protects the sign-in step, but a stolen session token represents a session that has already passed it. Short session lifetimes, device binding, and re-authentication for sensitive actions limit the damage.

Can HTTPS prevent session hijacking?

HTTPS prevents tokens from being read off the network, which stops one major method. It does not stop theft through XSS, malware on the device, or tokens leaked in logs, so cookie flags and good session management are still needed.