Session fixation: how it works, how to test it and how to fix it

Session fixation is a flaw where an application keeps the same session ID before and after login. The attacker gets a valid ID, puts it in the victim's browser, waits for the victim to sign in, and then uses that ID to act as the victim. CWE-384 names it. OWASP describes the attacker as setting the session ID on the victim's browser instead of stealing one.

Test only systems you own or have written authorization to test. Examples use a fictional app on example.com.

The attack in four steps#

1. The attacker opens the site and receives a session ID, for example abc123. The ID is not tied to a user yet.
2. The attacker makes the victim's browser use abc123. Ways to do this are in the next section.
3. The victim signs in. The app marks session abc123 as authenticated for the victim and does not change the ID.
4. The attacker sends requests with abc123 and is signed in as the victim.

GET / HTTP/1.1
Host: notes.example.com

HTTP/1.1 200 OK
Set-Cookie: sid=abc123; Path=/; HttpOnly

POST /login HTTP/1.1
Host: notes.example.com
Cookie: sid=abc123

HTTP/1.1 302 Found
Location: /notes

How attackers plant the ID#

The attack needs a way to place a chosen ID in the victim's browser. Which route works depends on how the app accepts IDs.

Fix: a new session ID at login#

The OWASP Session Management Cheat Sheet states that the session ID must be renewed after any privilege level change, and the previous ID must be destroyed. Login is the most common case. Password change, role change and step-up authentication also count. It also says apps should never accept a session ID they have never generated, and should refuse IDs sent in URL parameters.

PHP. Regenerate after the password check and turn on strict mode in php.ini. The PHP manual calls session.use_strict_mode mandatory for secure sessions and notes that it is off by default.

if (password_verify($password, $hash)) {
    session_regenerate_id(true);   // true deletes the old session file
    $_SESSION['user_id'] = $userId;
}

session.use_strict_mode = On
session.use_only_cookies = On
session.use_trans_sid = Off
session.cookie_httponly = On
session.cookie_secure = On
session.cookie_samesite = "Lax"

Node.js (Express with express-session). req.session.regenerate(callback) creates a new ID and a new session object. The module's own login example uses it before storing the user, as a guard against session fixation.

app.post("/login", (req, res, next) => {
  const user = authenticate(req.body);
  if (!user) return res.sendStatus(401);
  req.session.regenerate((err) => {
    if (err) return next(err);
    req.session.userId = user.id;
    req.session.save((err2) => (err2 ? next(err2) : res.redirect("/notes")));
  });
});

Python (Django). django.contrib.auth.login() calls cycle_key() to mitigate session fixation, according to the Django docs. Use login(). If you write your own login, call request.session.cycle_key() yourself before you store the user.

from django.contrib.auth import authenticate, login

user = authenticate(request, username=u, password=p)
if user is not None:
    login(request, user)   # cycles the session key

Java (Spring Security). Protection is on by default. The reference says Spring Security creates a new session or changes the session ID at login, and the default is changeSessionId on Servlet 3.1 and newer. Setting it to none is not recommended. Write out the strategy if you want it visible in code review:

http.sessionManagement(s -> s
    .sessionFixation(f -> f.changeSessionId()));

Other stacks. The rule is the same in Go, C#, Ruby and others: after authentication, delete the old server-side session record, create a new random ID, copy over only the data you need, and set a new cookie. Check your session library for a "regenerate" or "cycle" call, and read its documentation for what it keeps.

Framework defaults help only on the standard path. These custom paths break them:

Cookie settings that reduce the risk#

The OWASP cheat sheet lists the settings. They shrink the ways an ID can be planted or read, but none of them replaces renewal at login.

• Secure is mandatory so the ID is not exposed on plain HTTP.
• HttpOnly blocks script access, which closes the XSS route to reading the ID.
• SameSite=Strict (preferred) or Lax, set explicitly.
• Omit Domain and keep Path as narrow as possible, so sibling subdomains do not share the cookie.
• Use the __Host- prefix for session IDs. The cheat sheet says the browser then requires Secure, no Domain and Path=/, and that this prevents subdomain forgery and HTTPS downgrade attacks. Example from the sheet: Set-Cookie: __Host-SessionID=<value>; Secure; HttpOnly; SameSite=Strict; Path=/.
• Enforce expiry and invalidation on the server. Removing a cookie in the browser does not cancel a copy someone else holds.

SSO, OAuth and JWT cases#

Single sign-on adds a second place to lose the rule. The login finishes in a callback, and the callback code must create a new session before it records the identity. Three Jenkins CVEs show the pattern in login and plugin code (see the next section).

A signed JWT sent as a bearer token has no pre-login session value that the attacker can fix. That removes the classic attack, not the risk: stolen tokens, long lifetimes and weak validation remain. The JWT vulnerabilities guide covers those. If a JWT sits inside a server session or a cookie, test the cookie the same way as any other session ID.

Real CVEs#

All entries are from the National Vulnerability Database, checked 9 November 2026.

The second and third entries show where the fix gets missed: a sign-up flow and an SSO plugin.

How penetration testers detect and prove it#

OWASP WSTG-SESS-03 describes the test. The evidence standard is strict: a finding needs the same session ID value before and after authentication, and a replay of the pre-login ID that returns an authenticated page.

1. Request the login page without cookies. Save the response and the Set-Cookie header with a timestamp.
2. Sign in with a test-owned account, sending the pre-login cookie. Save the response.
3. Compare the cookie value before and after. A different value after login means the main fix is present. An unchanged value is the lead.
4. Replay the old value from a fresh client with no other cookies, to an endpoint that needs authentication. A 200 with the account's own data is the proof. A bare 200 on a public page proves nothing.
5. Run controls: replay a random invented ID (the server should reject it or issue its own), replay the ID after logout (it should fail), and repeat after each privilege change (password change, role change, MFA step-up).
6. Check other ways to plant an ID: put the ID in a query parameter and a form field, and see whether the server accepts it. Check the cookie's Domain, Secure, HttpOnly, SameSite and prefix.
7. Browser-observe the SSO and callback flows with Chromium developer tools, because the ID may change at one step and not at the next.

We record the request and response pair for each step with timestamps and the framework version, since defaults change between versions. We report the controls that held, for example "ID renewed at password login" and "random IDs rejected", next to any failure, so a fix does not break a working protection.

Session fixation, hijacking and CSRF#

See CSRF testing for the third column.

Testing checklist#

• Compare the session cookie before and after login, sign-up, SSO callback, password change and role change.
• Replay the pre-login ID and record whether an authenticated page returns.
• Send an ID the server never issued and check that it is rejected.
• Try the ID in a URL parameter and a form field.
• Check that logout destroys the server-side session and the old ID fails.
• Check Secure, HttpOnly, SameSite, Domain and the __Host- prefix.
• Check whether subdomains can set cookies for the parent domain.
• Check session lifetime and idle timeout on the server.
• Record the framework and library versions tested.

When to get a professional test#

Framework defaults hide this bug until a team adds custom login, an SSO callback or a new privilege level. A professional test walks every path that creates authenticated state, compares IDs at each one and keeps the evidence. See web application penetration testing for scope and deliverables, and the authentication testing checklist for the wider session checks. Testing starts only after written authorization from the system owner.