Session Fixation
Session fixation sets the victim session identifier before login — via URL, subdomain cookie, or header injection — so the post-login session reuses the attacker-known id.
Definition
Session fixation is an attack where the attacker establishes a session identifier for the victim before authentication, and the application keeps that identifier after login. The attacker then uses the known id to hijack the authenticated session. Defense is rotating the session id at every privilege change and rejecting ids from URLs.
Context and scope
Classic against applications accepting session ids from the query string, subdomain-writable cookies, or crafted Set-Cookie via middleware. Reactivates on partial-HTTPS sites and subdomain-rich deployments.
Common misconceptions
- HTTPS alone prevents it — an attacker can seed ids through URL sharing, subdomain cookies, and HTTP-injected headers on mixed-content sites
- Long random ids prevent it — entropy prevents guessing, not fixation; the problem is the attacker knowing the value before login
- Regenerating on logout is enough — regeneration belongs at every privilege elevation: login, role change, re-authentication
Anti-patterns
- Carrying session tokens in URLs and letting shared links seed ids
- Keeping the pre-auth session id after login for continuity of shopping carts
- Hosting user subdomains able to set cookies scoped to the parent domain where sessions live
Related concepts
Related examples
Authoritative source
What it is
The attack has two halves: make the victim use a session id the attacker knows, then let login promote that id to authenticated. The application hands over the keys by preserving the id across the privilege boundary.
How it works
Seeding channels: session id in the URL, a cookie set by a sibling subdomain, or an injected Set-Cookie from an HTTP path on a mixed site. The victim authenticates; the application binds authentication to the existing id; the attacker presents the same id and is the same session.
When to fix
Rotate ids at every privilege change, never accept ids from URLs or request bodies, and scope cookies with host-only settings plus __Host- prefixes. Frameworks expose regeneration; call it at login rather than relying on defaults.
Pitfalls
Cart continuity arguments preserve pre-login ids — copy state into the new session instead of keeping the id. Subdomain sprawl re-opens the cookie seeding channel even on hardened parents. Regeneration must invalidate the old id server-side, not merely issue a new Set-Cookie.