Category: Attack Techniques
Session Fixation
Also known as: Session Fixation Attack
Simply put
Session fixation is an attack in which an attacker tricks a user into authenticating with a session identifier that the attacker already knows or has set. Once the user logs in, the attacker can use that same session ID to access the user's authenticated session. The attack exploits web applications that fail to issue a new session identifier after a user successfully authenticates.
Formal definition
In a session fixation attack, the attacker establishes or obtains a valid session token prior to user authentication, then manipulates the target user into authenticating under that pre-known session identifier. This exploits a limitation in session management whereby the application does not regenerate the session ID upon privilege escalation or login, allowing the attacker to reuse the fixated identifier to impersonate the authenticated user. The attack differs from session hijacking in that the attacker fixes the session ID before authentication rather than stealing an existing authenticated token after the fact. Successful exploitation typically requires the application to accept externally supplied session identifiers and to preserve the same session ID across the authentication boundary.
Why it matters
Session fixation is significant because it allows an attacker to gain authenticated access to a victim's account without ever needing to steal credentials or crack a password. By pre-positioning a known session identifier before the user logs in, the attacker effectively bypasses the authentication step entirely. This makes the attack particularly dangerous in applications that handle sensitive personal, financial, or health data, where an authenticated session grants broad access to private resources.
Who it's relevant to
Web Application Developers
Developers building authentication flows must ensure that a new session identifier is issued immediately after a user successfully authenticates. Applications that reuse the same session ID across the authentication boundary are directly vulnerable. Developers should also avoid accepting session identifiers supplied through URL parameters or other user-controlled inputs, as this is a primary enabler of fixation attacks.
Application Security Engineers and Penetration Testers
Security engineers and testers should verify that session ID regeneration occurs at every privilege elevation point, including login, role changes, and checkout flows. Testing for session fixation typically involves supplying a known session token before authentication and confirming whether that token remains valid afterward. Static analysis tools alone cannot reliably detect session fixation because the vulnerability depends on runtime session management behavior rather than patterns visible in source code.
Security Architects
Architects designing session management frameworks should ensure that session handling libraries regenerate identifiers on state transitions by default. Relying on framework defaults without verifying this behavior can introduce fixation risk across an entire application portfolio. Architects should also evaluate whether the application exposes any mechanism that allows session IDs to be set or influenced by external input, such as query strings or hidden form fields.
Product and Risk Managers
Session fixation attacks can result in complete account takeover without requiring credential compromise, which makes them a meaningful risk in applications where authenticated sessions grant access to sensitive user data or privileged operations. Because the attack can be executed without direct network access to the victim's traffic, traditional network-layer controls typically offer limited protection, and the risk must be addressed at the application layer.
Inside Session Fixation
Pre-Authentication Session Token
A session identifier issued to a user before they have authenticated, which becomes the attack surface in session fixation. If this token is not replaced upon login, an attacker who knows or controls it can hijack the authenticated session.
Session Token Regeneration
The server-side mechanism of invalidating the pre-authentication session identifier and issuing a new, unpredictable token immediately upon successful authentication. This is the primary defense against session fixation.
Attacker-Controlled Token Injection
The method by which an attacker plants a known session identifier into the victim's browser, typically via URL parameters, meta-refresh tags, or cross-site scripting, before the victim authenticates.
Authentication Boundary
The point in application flow where a user's identity transitions from anonymous to authenticated. Session fixation exploits the failure to enforce a security boundary at this transition by not issuing a fresh session token.
URL-Based Session Identifiers
A common enabler of session fixation attacks where session tokens are passed in query strings, making them easier for an attacker to predict, distribute, or manipulate compared to cookie-based tokens.
Privilege Escalation Trigger
Any event that elevates a user's trust level within a session, such as login, step-up authentication, or role change. Best practice requires session token regeneration at each such trigger, not only at initial login.
Common questions
Answers to the questions practitioners most commonly ask about Session Fixation.
Does using HTTPS protect against session fixation attacks?
No. HTTPS encrypts data in transit and protects against interception, but it does not prevent session fixation. An attacker who can cause a victim to use a known session identifier (through URL parameters, subdomains, or other vectors) can still fix a session regardless of whether the connection is encrypted. HTTPS and session fixation are separate concerns that require separate controls.
If my application requires authentication, does that mean it is already protected against session fixation?
Not necessarily. Requiring authentication is a necessary step, but it is not sufficient on its own. The critical control is regenerating the session identifier upon successful authentication. If the application accepts the same session identifier before and after login, an attacker who planted that identifier before authentication can still use it after the victim logs in. Authentication without session regeneration leaves the fixation vector open.
When exactly should a new session identifier be issued to prevent session fixation?
A new session identifier should be issued at every privilege level change, most importantly upon successful authentication. It should also be issued when a user's role or permission level changes within a session. Simply invalidating the old identifier is not sufficient; the application must generate a new, unpredictable identifier and associate it with the newly authenticated context.
Should session identifiers ever be accepted from URL parameters or query strings?
In most cases, no. Accepting session identifiers from URL parameters is a common enabler of session fixation because URLs can be crafted by attackers and shared with victims. Session identifiers should typically be transmitted only via HTTP cookies with appropriate attributes such as HttpOnly and Secure. If URL-based session tracking is required for a specific use case, the application must never accept a session identifier from a URL parameter as a valid pre-authentication session that persists after login.
What cookie attributes help reduce the risk of session fixation?
Several cookie attributes reduce related risks. The HttpOnly attribute prevents client-side scripts from reading the session cookie, limiting some injection-based fixation vectors. The Secure attribute ensures the cookie is only sent over HTTPS. The SameSite attribute may limit cross-site delivery of the cookie. The Domain attribute should be scoped as narrowly as possible to prevent subdomain attacks from setting or overriding cookies. These attributes are complementary controls and do not replace the requirement to regenerate the session identifier at authentication.
How should an application handle an incoming session identifier that was set before the user authenticated?
The application should treat any pre-authentication session identifier as untrusted for post-authentication use. Upon successful login, the application should invalidate the existing session identifier, create a new session identifier, and transfer any necessary pre-authentication session data to the new session. The old identifier should not be reused or accepted after authentication is complete. Most modern session management frameworks provide methods to perform this regeneration, though correct configuration typically must be explicitly verified.
Common misconceptions
Session fixation and session hijacking are the same attack.
Session hijacking broadly refers to obtaining a valid session token by any means, including theft or prediction. Session fixation is a specific variant where the attacker supplies or plants the token before authentication, rather than stealing it afterward. The attacker knows the token from the start because they introduced it.
Using HTTPS fully prevents session fixation.
HTTPS protects session tokens from interception in transit but does not prevent session fixation. If the application accepts attacker-supplied session identifiers and does not regenerate the token at login, the attack remains viable regardless of transport-layer encryption.
Regenerating the session token only at initial login is sufficient.
Token regeneration is required at every privilege escalation boundary, including step-up authentication events and role changes within an active session. Fixation attacks can target any point where trust is elevated, not only the initial login transition.
Best practices
Regenerate the session identifier server-side immediately upon any successful authentication event or privilege escalation, and invalidate the previous token so it cannot be reused.
Avoid placing session identifiers in URLs or query parameters. Use cookies with the HttpOnly and Secure attributes set, and consider the SameSite attribute to limit cross-site token exposure.
Configure the application to reject or ignore session identifiers presented in the request that were not originally issued by the server, preventing attackers from injecting externally crafted tokens.
Set appropriate session token expiration and idle timeout policies so that pre-authentication tokens have a short lifespan, reducing the window of opportunity for an attacker to exploit a fixated token.
Apply output encoding and enforce Content Security Policy to reduce the risk of cross-site scripting, which is a common mechanism attackers use to inject or fix session tokens in the victim's browser.
Include session fixation scenarios in authentication-related test cases during security assessments, verifying through dynamic testing that the token returned after login differs from the token issued before login.