What is Session fixation?
An attack where the attacker fixes (chooses) a session ID that the victim is then authenticated under, allowing the attacker to use the same session ID to access the victim's account. Mitigated by regenerating session IDs at every privilege transition.
Full explanation
Session fixation works when an application accepts a session ID from the client (cookie, URL parameter) before authentication and continues using the same ID after authentication. The attacker plants a session ID on the victim (via a phishing link, an open-redirect-with-session-param, or compromised intermediary), the victim logs in, and the same session ID — now bound to the victim's identity — is in the attacker's possession. The defense is to regenerate the session ID on every privilege transition: anonymous → authenticated, regular user → step-up MFA verified, regular user → admin role.
Example
User visits your site via attacker-supplied link `https://your-app.com/?sessionId=ATTACKER123`. Your app's session middleware accepts the ID and creates a session. User logs in. The session for `ATTACKER123` is now authenticated as the user. Attacker visits with `Cookie: sessionId=ATTACKER123` and is logged in as the victim. Fix: on successful login, generate a NEW session ID + invalidate the pre-login one.
Related
FAQ
Does NextAuth or Clerk handle this?
Yes — both regenerate session IDs on login by default. Custom auth implementations are where this bug typically lands. If you wrote your session handling from scratch, audit the login flow: does session.id change before vs after successful authentication? If not, you have session fixation.
How does this differ from session hijacking?
Session hijacking is stealing an EXISTING session (XSS, network sniffing, predictable IDs). Session fixation is forcing the victim to use a session the attacker ALREADY KNOWS. Both end with the attacker having a valid session; the entry path differs.