Session Hijacking and the Cookies You Forgot to Secure

When you log into a website and it "remembers" you as you click around, that memory almost always lives in a session cookie — a small token your browser stores and sends back with every request, proving "I'm the person who logged in."

Which means that cookie is, effectively, your identity. Anyone who gets a copy of it can be you on that site — no password required. This is called session hijacking, and whether it's easy or nearly impossible comes down to a few small settings most people never think about.

Why the session cookie is such a prize

Passwords are protected by all sorts of ceremony: hashing, rate limits, maybe two-factor. But once you're logged in, the session cookie is what actually authenticates every subsequent action. Steal it, and you skip the entire login process. You inherit the victim's logged-in session directly — their account, their data, their permissions.

So the attacker's goal is simply: get a copy of that cookie. There are three main ways, and each maps to a cookie setting that stops it.

Threat 1: Reading the cookie with JavaScript

If your site has a Cross-Site Scripting flaw (see our XSS article), an attacker's injected script can read your cookies and send them off — instant hijack.

The defence: the HttpOnly flag. A cookie marked HttpOnly is invisible to JavaScript entirely. The browser still sends it with requests, so logins keep working, but no script can read it. This single flag neutralises the most common cookie-theft path. There's almost never a reason for a session cookie not to be HttpOnly.

Threat 2: Stealing the cookie in transit

If any part of your site is served over plain HTTP, cookies can be sent unencrypted across the network — where anyone on the same Wi-Fi, or sitting on the network path, can read them.

The defence: the Secure flag. A Secure cookie is only ever sent over HTTPS, never over plain HTTP. Combined with forcing HTTPS everywhere, it means the cookie never travels in a form anyone can intercept.

Threat 3: The cookie being sent from other sites

By default, browsers attach your cookies to requests even when those requests originate from another website. That's the mechanism behind Cross-Site Request Forgery (CSRF) — a malicious site quietly triggering authenticated actions on your site using the victim's cookie.

The defence: the SameSite attribute. Setting SameSite=Lax (a sensible default) or SameSite=Strict tells the browser not to send the cookie on cross-site requests, cutting off CSRF at the source. It's a small attribute with an outsized protective effect.

The pattern: three flags, one secure cookie

A properly protected session cookie looks like this:

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax; Path=/

Each flag closes a different door:

• HttpOnly — a script can't read it.
• Secure — the network can't sniff it.
• SameSite — other sites can't ride on it.

Miss any one, and you've left a door open. And here's the catch that makes this worth checking: the defaults are not always safe, and different frameworks, versions, and hand-rolled auth code (very common in AI-generated projects) set these inconsistently. A cookie that's missing HttpOnly in production is a genuinely common finding — and a serious one.

Beyond the flags

A few more good habits: rotate the session identifier when a user logs in (so a pre-set value can't be reused), give sessions a sensible expiry, and invalidate them server-side on logout. But the three flags are the foundation, and they're the part most often gotten wrong.

Where Safeey helps

You can't tell whether your cookies are secure just by using your site — the flags are invisible in normal browsing. Safeey inspects the actual Set-Cookie headers your server sends and reports exactly which of HttpOnly, Secure, and SameSite are present on each cookie, and which are missing. It turns an invisible, easy-to-miss weakness into a clear checklist.

Scan your site to see whether your session cookies are actually locked down.