How do you test for session fixation and prevent it?

Session fixation happens when an application keeps the same session identifier after a user logs in. An attacker who planted that identifier beforehand then shares the authenticated session. Test by comparing the session cookie before and after login. Prevent it by issuing a fresh identifier at every privilege change.

How does the attack work?

OWASP describes three steps. The attacker obtains a valid session identifier, often by simply visiting the site as an anonymous user. They get the victim's browser to use that identifier, through a link carrying it in the URL, a cookie set from a related subdomain, or injected script. The victim then logs in. If the server upgrades the existing session instead of creating a new one, the attacker's copy of the identifier is now logged in as the victim.

CWE-384 classifies this as a weakness where the application does not invalidate existing session identifiers when a user authenticates.

Where is it still found?

Applications that accept an identifier supplied by the client, for example from a URL parameter or a cookie they did not issue. Applications that store pre-login state (a cart, a locale, a CSRF value) and reuse the session to preserve it. Single sign-on and "remember me" flows that attach a new identity to an old session. Mixed environments where a legacy page sets a session cookie with a broad domain.

How do you test for it?

The OWASP Web Security Testing Guide has a simple procedure. Do this only against systems you are authorized to test.

1. Request the login page and record the session cookie the server sets (name and value).
2. Log in with a test account.
3. Compare the session cookie after login with the one before.
4. If the value is unchanged and the account is now authenticated, the application is vulnerable.
5. Repeat for other transitions: step-up authentication, role switching, and logout followed by login in the same browser.
6. Try presenting an identifier the server never issued. A server that accepts and adopts an arbitrary value is also vulnerable.

A constructed example: the cookie sid=abc123 is set on first visit. After a correct login the response sets no new cookie, and a request carrying sid=abc123 from a second browser returns the account page. That second browser never knew the password.

How do you prevent it?

The core fix is to generate a new session identifier whenever authentication state changes, and to invalidate the old one. Copy across only the data you need.

• Issue the new ID after login, after privilege change, and after password change. Destroy the old server-side session.
• Accept only identifiers the server generated. Reject unknown values instead of creating a session with them.
• Use long random identifiers from a cryptographically secure generator.
• Send the cookie with Secure, HttpOnly and an appropriate SameSite value, and never place identifiers in URLs.
• Set idle and absolute timeouts, and tie sessions to the account so a password reset ends them.
• Avoid cookies scoped to a parent domain that sibling apps can write.

Most mature frameworks have a built-in call. Spring Security enables session fixation protection by default, Express with express-session offers req.session.regenerate(), and Django rotates the session key during login. Confirm in your version's documentation and in a test, because custom login code often bypasses the built-in path.

What to do

1. Run the before and after login cookie comparison on every login flow.
2. Call your framework's session regeneration at each authentication change.
3. Reject client-supplied identifiers the server did not issue.
4. Set cookie flags and remove identifiers from URLs.
5. Add an automated test that fails if the cookie value survives login.
6. Review subdomains that can set cookies for the parent domain.

Quick check

Sources

• OWASP: Session fixation
• OWASP WSTG: Testing for Session Fixation
• OWASP Session Management Cheat Sheet
• CWE-384: Session Fixation

Last reviewed: 18 October 2026.