What Is a Session Fixation Attack and How Do You Prevent It?
Learn what a session fixation attack is and how regenerating the session ID at login prevents it.
Expected Interview Answer
Session fixation is an attack where an attacker sets or predicts a victim’s session identifier before login and then, once the victim authenticates using that same identifier, reuses it themselves to hijack the now-authenticated session, and the fix is to always issue a brand-new session ID at the moment of successful login.
In a vulnerable app, the session ID assigned when a user first visits the site stays the same after they log in — the server just marks that existing session as authenticated rather than issuing a fresh one. An attacker exploits this by obtaining a valid pre-login session ID (from the app itself, or by planting one via a crafted link, a subdomain cookie, or a vulnerable session-ID-in-URL scheme) and tricking the victim into using it, for example by sending a login link containing that fixed session ID. When the victim logs in, the server elevates that same session to an authenticated state, and because the attacker already knows the ID, they can use it in their own browser to ride the now-privileged session without ever knowing the victim’s password. The fix is regenerating the session identifier — calling something like session.regenerate() or issuing a new signed cookie — immediately after successful authentication, so any pre-login ID an attacker planted becomes worthless the moment real login happens, combined with never accepting session IDs from URL parameters and binding sessions to characteristics like IP or user-agent where practical.
- Regenerating the session ID at login invalidates any attacker-planted pre-login ID
- Prevents session hijacking even if the attacker knows the pre-login session identifier
- Complements other cookie hardening (HttpOnly, Secure, SameSite) rather than replacing it
- Closes a distinct attack class that CSRF/XSS defenses alone do not cover
AI Mentor Explanation
Session fixation is like a con artist handing a fan a pre-printed wristband before the gates even open, then waiting for that fan to get it validated at the VIP desk after showing ID. Once validated, the con artist walks up wearing an identical wristband with the same code and strolls straight into the VIP section, since security only checks the code, not who originally wore it. The fix is for the VIP desk to punch a brand-new, unique code onto the wristband at the moment of validation, making any pre-handed wristband worthless. That regenerate-on-authentication step is exactly how session fixation is prevented.
Step-by-Step Explanation
Step 1
Attacker obtains/plants a session ID
Via a crafted link, subdomain cookie, or URL-based session scheme, before the victim logs in.
Step 2
Victim authenticates using that ID
The vulnerable server merely elevates the existing session to authenticated state.
Step 3
Attacker reuses the same ID
Knowing the ID in advance, the attacker sets it in their own browser to ride the now-privileged session.
Step 4
Fix: regenerate on login
The server issues a brand-new session ID at the moment of successful authentication, invalidating anything pre-planted.
What Interviewer Expects
- Clear articulation of the pre-login-ID-then-elevate mechanism that makes fixation possible
- Understanding of why regenerating the session ID at login is the definitive fix
- Awareness that this is distinct from session hijacking (stealing an existing ID) and CSRF
- Mention of complementary hardening: no session IDs in URLs, cookie flags, session binding
Common Mistakes
- Confusing session fixation with session hijacking or CSRF
- Believing HttpOnly/Secure cookie flags alone prevent fixation (they do not — regeneration does)
- Forgetting that session IDs accepted from URL parameters are especially vulnerable
- Not regenerating the session ID on privilege changes, not just initial login
Best Answer (HR Friendly)
“Session fixation is when an attacker tricks you into using a session ID they already know before you log in, and if the site doesn’t give you a fresh ID after you log in, the attacker can use that same ID to access your now-logged-in account. The fix is simple: always issue a brand-new session identifier the moment someone successfully logs in, so any ID an attacker planted beforehand stops working.”
Code Example
app.post('/login', async (req, res) => {
const user = await authenticate(req.body.email, req.body.password)
if (!user) return res.status(401).json({ error: 'Invalid credentials' })
// Regenerate the session ID before marking it authenticated
req.session.regenerate((err) => {
if (err) return res.status(500).json({ error: 'Login failed' })
req.session.userId = user.id
req.session.authenticatedAt = Date.now()
res.json({ ok: true })
})
})Follow-up Questions
- How is session fixation different from session hijacking?
- Why is passing session IDs in URL query parameters especially risky?
- Should the session ID also be regenerated on privilege escalation, like admin mode?
- How do SameSite and Secure cookie flags complement session regeneration?
MCQ Practice
1. What is the definitive fix for session fixation?
Issuing a new session ID at login invalidates any ID an attacker planted before authentication.
2. How does an attacker typically plant a session ID in a fixation attack?
Fixation relies on getting the victim to use an attacker-known session ID before authenticating.
3. Session fixation is best described as distinct from which other attack?
Fixation plants a known ID before login; hijacking steals an already-valid session ID afterward.
Flash Cards
What is session fixation? — An attacker plants a known session ID before login, then reuses it after the victim authenticates.
What is the definitive fix? — Regenerate the session ID immediately upon successful authentication.
How does fixation differ from hijacking? — Fixation plants a pre-login ID; hijacking steals an already-authenticated ID.
What complementary practice reduces fixation risk? — Never accept session IDs from URL parameters.