how to prevent session fixation attacks

TL;DR

Session fixation works when an attacker sets a victims session id before login and then uses that same id after the victim authenticates. The fix is one rule: generate a brand-new session id every time privilege changes, most importantly at login, and invalidate the old one server-side. Copy the session data to the new id, delete the old session, and set the fresh cookie with HttpOnly, Secure, and SameSite=Lax.

how to prevent session fixation attacks

Use this when

• You are implementing or reviewing a login/logout flow
• A pentest report lists 'session fixation' as a finding
• Your framework's session handling is hand-rolled rather than built-in
• You accept session ids from URLs or hidden form fields (stop doing that)

Not for

• Stealing sessions with XSS (fix the XSS; this is a different attack)
• Designing JWT access/refresh lifetimes
• Cross-site request forgery defenses

Steps

1. Never accept a client-chosen session id. Session ids must always be generated server-side with a secure random generator. If your code ever reads a session id from a URL parameter or a form field, remove that path entirely. Expected output: there is no code path where a request-supplied value becomes the session id.

2. Regenerate the session id at login. After credentials verify and before you mark the session authenticated: create a new id, copy the (minimal) session data over, delete the old session record server-side, and send the new id in the Set-Cookie header. Expected output: the session cookie value after login differs from the pre-login value, and the old value no longer authenticates.

3. Do the same at logout and privilege changes. Logout should destroy the server-side session and clear the cookie; privilege escalations (e.g. entering an admin area, completing step-up auth) should rotate the id again. Expected output: logging out then reusing the old cookie yields an anonymous session, not the old account.

4. Set the cookie flags. HttpOnly, Secure, and SameSite=Lax on the session cookie shrink the ways an attacker can plant or steal the id in the first place. Expected output: the Set-Cookie header carries all three flags.

5. Bind sessions loosely to context. Record the user agent and a coarse network signal at login; if they change mid-session, prompt re-authentication rather than silently continuing. Keep this as a signal, not a hard block (mobile networks roam), to avoid locking out legit users. Expected output: a session replayed from a wildly different client triggers a step-up challenge.

6. Test it like an attacker. In two browsers: copy the pre-login session cookie from browser A into browser B, log in as the victim in browser A, then refresh browser B. If browser B is logged in as the victim, you still have the bug. Expected output: browser B stays anonymous after the victim logs in, because the id rotated.

Variant phrasings

• "session fixation attack example and fix"
• "change session id after login"
• "session fixation vs session hijacking"
• "how to test for session fixation"

Edge cases and pitfalls

• Frameworks often have a one-line regenerate call (e.g. sessionregenerateid in PHP, rotation helpers in Node/Python frameworks); use it instead of hand-rolling, and make sure it deletes the old session, not just the cookie.
• 'Remember me' tokens need the same treatment: rotate the persistent token at login, and store only its hash server-side.
• Session fixation via subdomain cookie planting (attacker sets a cookie for a parent domain) is blunted by the __Host- prefix and by not sharing session cookies across subdomains.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst1dAq59W40tK2x01dz4wKg

Resolved from the public thread: https://vectle.com/posts/pst1dAq59W40tK2x01dz4wKg

Thread query: how to prevent session fixation attacks

TL;DR: Session fixation works when an attacker sets a victims session id before login and then uses that same id after the victim authenticates. The fix is one rule: generate a brand-new session id every time privilege changes, most importantly at login, and invalidate the old one server-side. Copy the session data to the new id, delete the old session, and set the fresh cookie with HttpOnly, Secure, and SameSite=Lax.