Session fixation is a cybersecurity attack in which a criminal causes a victim to use a session identifier that the attacker already knows.
The victim then signs in using that identifier. If the application keeps the same session ID after authentication, it becomes linked to the victim’s authenticated account. The attacker can reuse their known copy of the identifier and may be treated as the logged-in user.
Unlike many other forms of session hijacking, the attacker does not need to steal the session token after login. They arrange for the victim to authenticate with a token already under the attacker’s control.
A successful session-fixation attack may allow someone to:
- Enter the victim’s account
- Read private information
- Change security settings
- Send messages
- Access stored files
- Make purchases or transactions
- Create persistent access
- Use administrative privileges
- Take control of the account
MITRE classifies this weakness as CWE-384: Session Fixation. It occurs when an application authenticates a user without invalidating the existing session identifier. MITRE’s CWE-384 entry explains the vulnerability.
What Is a Session Identifier?
A session identifier, also called a session ID or session token, is a value an application uses to recognize a user across multiple requests.
Before login, a website may create an anonymous session to store:
- Shopping-cart items
- Language preferences
- Form progress
- Tracking information
- Login-state data
- Anti-CSRF tokens
After successful login, the application connects an authenticated identity to a session.
A secure application must create a fresh session identifier when authentication or privilege level changes. If it upgrades the old anonymous session without changing its identifier, anyone who already knows that identifier may inherit the authenticated session.
How Does Session Fixation Work?
A typical session-fixation attack follows this pattern:
- The attacker obtains a valid anonymous session from the application.
- The attacker records its session identifier.
- The victim is caused to use the same identifier.
- The victim signs in normally.
- The application associates the authenticated account with the existing identifier.
- The server does not invalidate or replace the identifier.
- The attacker sends their known copy of the token.
- The application treats the attacker as the victim.
The password may be strong, and the victim may even complete MFA. The vulnerability exists because the application keeps using the attacker-known session after those checks.
Why Is Session Fixation Dangerous?
Session fixation targets the connection between an anonymous session and an authenticated identity.
Once the known identifier becomes authenticated, the attacker may receive the same access as the victim without knowing:
- The password
- The one-time code
- The authentication answer
- The security-key response
- The recovery information
Possible consequences include:
- Account takeover
- Identity theft
- Financial fraud
- Personal-data exposure
- Administrative compromise
- Theft of company information
- Unauthorized account changes
- Creation of API credentials
- Movement into connected applications
The impact is especially serious when the victim is an administrator or other privileged user.
Session Fixation vs. Session Hijacking
Session hijacking is the broader category in which an attacker takes control of a valid user session.
Session fixation is one specific method of session hijacking.
In ordinary session theft, the attacker obtains the token after the victim authenticates. In session fixation, the attacker knows or controls the token before authentication and waits for the victim to log in with it.
Session Fixation vs. Session Prediction
Session prediction involves guessing or calculating a valid session identifier because token generation is weak.
Session fixation does not necessarily require the token to be predictable. The attacker may legitimately obtain a random anonymous session and then cause the victim to use it.
Both attacks may result in session hijacking, but they exploit different session-management weaknesses.
Session Fixation vs. Authentication Bypass
Authentication bypass avoids or defeats the login process.
With session fixation, the victim normally completes authentication successfully. The attacker then reuses the fixed session to inherit the result.
The attacker does not directly bypass the password check; they exploit the application’s failure to separate anonymous and authenticated sessions.
Session Fixation vs. CSRF
Cross-Site Request Forgery, or CSRF, tricks an authenticated browser into performing an unwanted action.
Session fixation happens before or during login. It causes the victim to authenticate using an identifier known to the attacker.
The two vulnerabilities may interact, particularly when a malicious site can influence pre-authentication state or login requests.
Session Fixation vs. Login CSRF
Login CSRF causes a victim to become signed in to an account controlled by the attacker.
The victim may then unknowingly add personal information, payment data, search history, or other sensitive content to the attacker’s account.
Session fixation usually has the opposite goal: the attacker wants to gain access to the victim’s account after the victim authenticates.
Both exploit confusion around login state and session transitions.
Common Types of Session Fixation
URL-Based Session Fixation
Some applications accept the session identifier in a URL parameter or path.
An attacker may send the victim a link containing a session value already known to the attacker.
URL-based sessions are particularly risky because identifiers can leak through:
- Browser history
- Referrer headers
- Server logs
- Shared links
- Bookmarks
- Screenshots
- Analytics systems
Session identifiers should not be transported in URLs.
Cookie-Based Session Fixation
An attacker may attempt to set or influence the browser’s session cookie.
This can become possible through:
- A vulnerable subdomain
- Cross-Site Scripting
- HTTP response splitting
- Weak cookie scope
- Unencrypted traffic
- Browser or proxy behavior
- Another application sharing the same cookie domain
Restrictive cookie settings and session regeneration reduce this risk.
Hidden-Field Session Fixation
Some applications place session state or identifiers inside hidden form fields.
Hidden fields are visible and controllable by the user. They must not be treated as trusted security controls.
The server should manage authenticated session identity through secure server-side mechanisms.
Request-Parameter Fixation
A session token may be accepted through a query parameter, request body, or another client-controlled value.
The application may accept whichever identifier the client supplies rather than creating a secure server-controlled session.
Subdomain Session Fixation
A vulnerable or less trusted subdomain may set a broadly scoped cookie that is later sent to the main application.
If the primary application accepts that cookie as its session identifier and does not rotate it after login, the attacker may fix the session.
Sensitive cookies should have the narrowest practical domain scope.
Cross-Site Scripting Fixation
An XSS vulnerability may allow malicious JavaScript to manipulate session-related browser state before the victim authenticates.
Although HttpOnly prevents ordinary JavaScript from reading protected cookies, it does not correct every form of application or cookie manipulation. Eliminating XSS remains essential.
Network-Based Session Fixation
If an application permits HTTP or has incomplete transport protection, a network attacker may manipulate traffic and introduce a known session identifier.
HTTPS and the Secure cookie attribute help prevent interception and manipulation over the network.
Pre-Authentication Session Fixation
Many applications create a session before login.
The vulnerability appears when the application upgrades that same identifier to authenticated status instead of destroying it and creating a fresh session.
This is the classic form of session fixation.
Privilege-Elevation Fixation
Session regeneration should occur not only at login but also when privileges increase.
For example, a user may switch from:
- Anonymous to authenticated
- Password-only to MFA-verified
- Standard user to administrator
- Customer to support impersonation mode
- Low-assurance to high-assurance access
Keeping the same token across these transitions increases risk.
SSO Session Fixation
Single Sign-On workflows move through multiple systems and redirects.
A fixation risk may appear if:
- Pre-login state is reused
- Session identifiers are accepted from the client
- Login callbacks do not rotate the local session
- Identity-provider state is confused with application session state
- Account linking occurs without a fresh session
The application should regenerate its local session after successful federated authentication.
Mobile Application Session Fixation
Mobile applications may preserve identifiers in:
- Local preferences
- Deep links
- Embedded browsers
- Web views
- Shared storage
- Custom authentication callbacks
A mobile backend should issue a new authenticated token rather than upgrading an attacker-influenced pre-login identifier.
Where Do Session-Fixation Vulnerabilities Appear?
Common locations include:
- Traditional web logins
- E-commerce sites
- Customer portals
- Administrative dashboards
- Banking applications
- Healthcare platforms
- Learning-management systems
- Single Sign-On integrations
- OAuth or OpenID Connect clients
- Mobile application web views
- Support impersonation tools
- Legacy applications
- Shared-domain applications
- Systems accepting URL-based sessions
Applications using framework-provided session management may still be vulnerable if developers disable or incorrectly use the framework’s session-regeneration features.
What Causes Session Fixation?
The main cause is failing to issue a new session identifier when authentication or privilege level changes.
Contributing problems include:
- Reusing anonymous sessions after login
- Accepting session IDs from URL parameters
- Allowing the client to choose a session identifier
- Broad cookie domain scope
- Weak subdomain isolation
- Missing HTTPS
- Missing Secure cookie attributes
- Cross-Site Scripting
- Unsafe SSO callbacks
- Incorrect framework configuration
- Failure to invalidate the old session
- Long session lifetimes
- Missing session revocation
- Inconsistent session handling across endpoints
- Reusing tokens after MFA or role changes
OWASP states that session ID regeneration is mandatory during authentication and other privilege-level changes to prevent fixation. OWASP’s Session Management Cheat Sheet provides implementation guidance.
Warning Signs of a Session-Fixation Attack
Security teams may observe:
- The same session ID before and after login
- Sessions created on one device and authenticated on another
- A session used from multiple locations after login
- Authenticated use without a corresponding login from the same device
- Session IDs supplied through URLs
- Repeated anonymous sessions later associated with privileged users
- Cookies set by unexpected subdomains
- Session identifiers accepted from request parameters
- Administrator sessions retaining pre-login tokens
- Old tokens remaining valid after session rotation
- Authentication events followed by access from a different device
- Unusual support or SSO session transitions
The key technical sign is an identifier that survives a change from unauthenticated to authenticated or from lower to higher privilege.
How Can Developers Prevent Session Fixation?
Regenerate the Session ID After Login
Immediately after successful authentication:
- Invalidate the old identifier.
- Generate a new cryptographically random identifier.
- Associate the authenticated account with the new session.
- Ensure the old identifier can no longer access protected resources.
This is the primary defense.
Destroy the Pre-Authentication Session
A pre-login session should not simply become the authenticated session.
Transfer only the minimum safe state required, such as a shopping cart or language preference, into a newly created authenticated session.
Do not copy untrusted security state.
OWASP’s CSRF guidance similarly warns that pre-sessions should be destroyed and replaced after authentication rather than transitioned into real sessions. OWASP’s CSRF Prevention Cheat Sheet discusses this requirement.
Rotate Sessions After Privilege Changes
Create a fresh identifier after:
- MFA completion
- Password reset
- Account recovery
- Role elevation
- Administrator impersonation
- Permission changes
- Authentication-assurance upgrades
Any meaningful increase in trust should create a new session boundary.
Invalidate the Old Token
Generating a new token is not enough if the previous token remains valid.
The old session must be removed or marked invalid on the server.
For stateless tokens, use short lifetimes and an appropriate revocation or token-version strategy for high-risk transitions.
Use Framework Session Functions
Use the maintained framework’s official session-regeneration and invalidation functions.
Avoid implementing custom session-ID generation or manual cookie replacement unless absolutely necessary.
Verify through testing that the old identifier is actually invalidated.
Do Not Accept Session IDs in URLs
Use securely configured cookies or appropriate authorization headers.
Reject unexpected session identifiers supplied through query strings, paths, or form fields.
Prevent User-Controlled Session IDs
The server should generate session identifiers.
Do not allow the browser, mobile application, or API client to choose the identifier used for an authenticated session.
Use Cryptographically Secure Randomness
A new session ID must be unpredictable and contain sufficient entropy.
Do not derive it from:
- Usernames
- Email addresses
- Timestamps
- Sequential counters
- Device IDs
- IP addresses
- Weak random functions
Use HTTPS Everywhere
Protect login and all authenticated pages with HTTPS.
Transport encryption prevents many network attackers from injecting, modifying, or capturing session identifiers.
Set the Secure Cookie Attribute
The Secure attribute tells the browser to send the session cookie only through HTTPS.
This reduces the risk of leaking it over an unencrypted request.
Set the HttpOnly Attribute
HttpOnly prevents ordinary JavaScript from reading the cookie.
It reduces straightforward session theft through XSS, although developers must still eliminate XSS because malicious scripts can perform actions within the active browser session.
Configure SameSite
An appropriate SameSite setting can reduce unwanted cross-site cookie transmission.
The correct setting depends on whether the application uses legitimate cross-site login and integration flows.
Restrict Cookie Domain and Path
Sensitive session cookies should have the narrowest practical scope.
Avoid sharing authentication cookies across unrelated or less trusted subdomains.
Where possible, use host-only cookies for high-value sessions.
Use Cookie Prefixes
Modern browsers support security-related cookie prefixes that can impose requirements such as Secure transport and host-only scope.
Use them when compatible with the application’s architecture.
Prevent XSS
Use:
- Context-aware output encoding
- Safe templating
- HTML sanitization
- Content Security Policy
- Secure browser APIs
- Dependency updates
- HttpOnly cookies
XSS may assist with fixation or allow direct abuse of an authenticated session.
Remove Session IDs From Logs
Do not record session tokens in:
- Access logs
- Debug logs
- Analytics
- Error messages
- Support systems
- Monitoring platforms
Redact authentication credentials at the logging boundary.
Apply Session Timeouts
Use:
- Idle timeouts
- Absolute timeouts
- Token expiration
- Server-side revocation
Timeouts limit the period during which an exposed token remains useful, though they do not replace regeneration.
Reauthenticate Sensitive Actions
Require current credentials or another strong confirmation before:
- Changing a password
- Replacing MFA
- Modifying recovery information
- Creating API keys
- Transferring funds
- Deleting an account
- Changing administrator roles
This reduces the impact if a session has been compromised.
Test SSO Session Transitions
After federated login, confirm that:
- The pre-login local session is invalidated
- A new authenticated session is created
- State and nonce are validated
- The old session cannot access authenticated resources
- Account linking requires deliberate verification
Can MFA Prevent Session Fixation?
Not by itself.
The victim may complete MFA while using the attacker-known session identifier. If the application retains that identifier, the attacker may inherit the MFA-verified session.
The application must rotate the session after MFA completion.
Does HTTPS Prevent Session Fixation?
HTTPS prevents many network-based attempts to inject or manipulate session identifiers.
However, it does not correct:
- Reuse of a pre-login session
- URL-based session identifiers
- Client-controlled tokens
- XSS-assisted fixation
- Broad cookie scope
- Incorrect application logic
Session regeneration remains necessary even on a fully encrypted website.
Can Strong Random Tokens Prevent Session Fixation?
Not completely.
Strong randomness prevents guessing but does not stop an attacker from legitimately obtaining their own random anonymous session and causing the victim to use it.
The application must replace the identifier after authentication.
Can a Web Application Firewall Prevent Session Fixation?
A WAF may block session IDs in suspicious URLs or known attack patterns.
It cannot reliably determine whether the application reused the same legitimate session identifier after login.
The root cause must be fixed in session-management logic.
How Should Session Fixation Be Tested?
Testing must be performed only with explicit authorization and designated accounts.
A controlled assessment should determine:
- Whether the session ID changes after login
- Whether the previous ID becomes invalid
- Whether it changes after MFA
- Whether it changes after privilege elevation
- Whether the client can supply a session ID
- Whether URLs can contain valid session identifiers
- Whether subdomains can set the session cookie
- Whether logout invalidates the session
- Whether SSO callbacks rotate the session
- Whether simultaneous use is detected
Testing should compare anonymous and authenticated session states without accessing real user accounts.
How Can Organizations Detect Session Fixation?
Useful monitoring includes:
- Session creation
- Login events
- Session-ID rotation
- Token invalidation
- Device and browser information
- Network location
- SSO callbacks
- Privilege-change activity
- Administrator actions
- Cookie-setting behavior
High-value detections include:
- No token rotation after login
- The same token used by different devices
- Old session IDs accessing authenticated resources
- Sessions authenticated from one client and used from another
- Privileged sessions retaining anonymous identifiers
- Session cookies set by unexpected subdomains
What Should an Organization Do After Detecting Session Fixation?
Correct Session Rotation
Update the application so every authentication and privilege transition creates a new session identifier and destroys the old one.
Revoke Existing Sessions
Invalidate active sessions affected by the vulnerable mechanism.
If the scope is unclear, revoke all sessions and require users to authenticate again.
Preserve Evidence
Collect:
- Session creation records
- Login events
- Session identifiers in hashed or safely handled form
- Device information
- Network addresses
- Account changes
- Privileged actions
- SSO activity
- Token-rotation events
Avoid copying raw session tokens into tickets or unsecured investigation notes.
Determine the Scope
Investigators should identify:
- Which accounts were affected
- Whether administrator sessions were compromised
- How long the flaw existed
- Whether fixed sessions were reused
- Which data was accessed
- Which settings changed
- Whether persistence was created
Reverse Unauthorized Changes
Restore:
- Passwords
- MFA settings
- Recovery information
- Account roles
- API credentials
- Connected applications
- Modified or deleted data
Rotate Related Secrets
If administrative accounts or sensitive configuration were exposed, rotate potentially affected:
- API keys
- Signing secrets
- Database credentials
- Cloud tokens
- Service-account credentials
- Administrative passwords
Notify Affected Users
Provide clear information about the incident and require affected users to sign in again.
Follow applicable privacy, contractual, and regulatory requirements.
Review Similar Applications
Session fixation often results from a shared framework configuration or development pattern.
Review:
- Other login endpoints
- Mobile applications
- SSO clients
- Administrative systems
- Password-reset flows
- MFA transitions
- Support impersonation features
What Should a User Do After Suspected Session Fixation?
If you believe someone accessed your account:
- Sign out all active sessions.
- Change your password.
- Enable or reset MFA.
- Review logged-in devices.
- Remove unfamiliar connected applications.
- Revoke unknown API keys.
- Check recovery email addresses and phone numbers.
- Review recent account activity.
- Contact the service provider.
- Use a trusted device for recovery.
The service provider must fix the underlying session-management vulnerability.
Can Session Fixation Lead to Account Takeover?
Yes.
Once the victim authenticates with the fixed session, the attacker may gain the same account access.
They may make the takeover persistent by changing the password, recovery information, MFA factors, or API credentials.
Is Session Fixation Only a Website Vulnerability?
No.
The same underlying flaw can affect:
- Mobile applications
- Desktop clients
- APIs
- Single Sign-On systems
- Embedded browsers
- Administrative tools
- Customer portals
- Internet of Things platforms
Any system that upgrades an attacker-known anonymous session into an authenticated session may be vulnerable.
