Session fixation is a flaw where an application keeps the same session ID before and after login, so an attacker who planted a known ID in a victim's browser can use it once the victim signs in. Test it by comparing cookies before and after login. The fix is to issue a new ID at login.
How the attack works
The OWASP Web Security Testing Guide explains that this is enabled by preserving the same value of the session cookies before and after authentication. It often happens when the app uses a session before login, for example to hold a shopping cart.
- The attacker gets a session cookie from the site without logging in.
- The attacker forces that cookie into the victim's browser by some means.
- The victim logs in. If the cookie is not refreshed, the session is now authenticated.
- The attacker, who knows the cookie value, acts as the victim.
The attacker never needed the password. They only needed the application to promote an existing session to a logged-in one.
How to test for it
You need two browser profiles or a proxy, and a test account.
- Open the site without logging in and record the session cookie name and value.
- Log in with the test account in the same browser.
- Record the session cookie again.
- Compare. If the value is the same, the application is vulnerable to fixation. If it changed, the app regenerates the ID correctly.
Also repeat the check for other privilege changes. OWASP's cheat sheet says the ID must be renewed after any privilege level change, with login as the most common case, and it lists password changes, permission changes and switching from a regular role to an administrator role as others.
Some sites use more than one cookie. Check each, since one cookie may be refreshed while another that actually identifies the session is not.
What scanners can and cannot do
An authenticated scanner can run the same before and after comparison automatically, which makes this one of the checks that automation does well. Things it can miss:
- Login flows with extra steps such as multi-factor prompts, where the ID may be rotated at the wrong step.
- Apps that put the session in a header or local storage rather than a cookie.
- Cookies set by a different subdomain than the one being scanned.
- Privilege changes beyond login, which a scan has no reason to trigger unless configured.
The fixes
| Fix | What it does |
|---|---|
| Regenerate the session ID on login | Makes any pre-login ID useless |
| Regenerate on privilege change | Covers password change and role switches |
| Use prefixed cookie names | The testing guide suggests the __Host- or __Secure- prefix to protect cookie integrity against network attackers |
| Enable full HSTS | The same guide recommends full HSTS, covering subdomains, for the same reason |
Most frameworks offer a one line call to rotate the session ID. Our post on resetting the session after login in Rails shows one example. Match the fix to your framework and test again afterward.
Quick check
Does HTTPS prevent session fixation?
No. HTTPS protects traffic in transit but does not change whether the server reuses a session ID across login. You still need to regenerate the ID.
Is this the same as session hijacking?
They are related. Hijacking steals an ID the victim already has. Fixation makes the victim adopt an ID the attacker already knows.
Try it yourself
Click through it at your own pace, or open it full screen. See how a scan records the cookies it sees while it crawls.
Safeguard offers a free scan of your dependencies at gold.safeguard.sh/scan, useful for checking the session libraries you rely on.
Sources
Last reviewed: 19 October 2026.
