Nobody guessed a password and nobody stole a cookie. The attacker asked your app for a session ID while signed out, arranged for your browser to carry the same one, and then waited for you to log in and make it valuable.
How is session fixation different from session hijacking?
Hijacking is theft after the fact, so the attacker has to get hold of a live session cookie somehow. Fixation is arranged in advance and needs no theft, because the attacker picked the ID. That difference is why an httpOnly cookie defeats one and not the other.
How do I fix session fixation?
Issue a brand new session ID the moment authentication succeeds and delete the old one. That single change closes the whole attack, because the ID the attacker holds stops pointing at anything. Do the same on password change and on any role change.
Does httpOnly or SameSite stop session fixation?
No. Both exist to stop an attacker reading or sending your cookie, and fixation needs neither. Keep them, they are doing other useful work, but regeneration at the privilege boundary is the control for this one.
How do I test whether my app is vulnerable?
Open your app signed out, copy the session cookie value from devtools, sign in, and look again. Identical value means no regeneration happened and fixation works. It is about a thirty-second check and it needs no tools beyond the browser.
::
The source
---
title: "The planted session ID survives login"
---
sequenceDiagram
autonumber
participant A as The attacker
participant S as Your app
participant B as Your browser
A->>S: opens your site, signed out
S-->>A: here is a session ID: abc123
Note over A,B: then mails you a link with abc123 in it
rect rgb(254, 242, 242)
B->>S: you sign in, still carrying abc123
S-->>B: welcome back. same session ID.
end
A->>S: reloads, still holding abc123
S-->>A: your account, your data
Note over A,B: nothing was stolen. your app reused the ID<br/>instead of issuing a new one at sign-in.
Does Your Login Issue a New Session?
CheckYourVibe reads what your deployed app actually sets, including a session cookie that never changes across the login boundary.