What this usually means
Session fixation occurs when the application accepts a session ID from an untrusted source (e.g., URL query parameter, cookie) and does not issue a new session ID after a privilege level change like login. The classic fix is `session_regenerate_id()`, but if called too late (after authentication data is stored) or not called on every privilege escalation (e.g., 2FA step-up, admin elevation), the old session ID remains valid with the new privileges. The root cause is a race condition between session data storage and session ID issuance; even a single line ordering error can make the fix ineffective.
The first ten minutes — establish facts before touching code.
- 1Intercept login request/response with Burp Suite or browser dev tools; note the `session` cookie value before and after login.
- 2If cookie value is identical, session fixation is confirmed; check code for `session_regenerate_id()` call location.
- 3In PHP, grep for `session_regenerate_id` and verify it appears before any `$_SESSION` write of user identifier.
- 4In Java (Tomcat), check if `request.changeSessionId()` is called after `request.getSession().setAttribute("user", ...)`.
- 5In Node.js (express-session), verify `req.session.regenerate()` is called before setting `req.session.userId`.
- 6Test with a pre-set session ID by crafting a URL like `http://example.com/?PHPSESSID=attacker_known_id` and observe if login uses that ID.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchLogin controller / authentication handler (e.g., login.php, AuthController.java, auth.js).
- searchSession configuration files (php.ini, web.xml, session middleware options).
- searchOAuth callback endpoint if using external providers (often forgotten).
- searchTwo-factor authentication verification endpoint (step-up authentication).
- searchPassword reset flow – some frameworks regenerate session here too.
- searchLoad balancer / reverse proxy logs for session ID reuse patterns.
- searchSecurity scanner reports (OWASP ZAP, Burp Suite) – look for 'Session Fixation' alerts.
Practical causes, not theory. These are the things you will actually find.
- warning`session_regenerate_id()` called after setting `$_SESSION['user_id']` – the new session ID copies old data.
- warning`session_regenerate_id()` called but with `delete_old_session=false` (PHP) – old session file still valid.
- warningCustom session management bypasses built-in regeneration (e.g., manual cookie setting).
- warningOnly regenerated on initial login, not on privilege escalation (e.g., admin impersonation, 2FA completion).
- warningMiddleware order: session middleware runs before auth middleware, and auth middleware doesn't regenerate.
- warningFramework bug: older versions of Symfony, Laravel, or Spring Security had known fixation issues.
- warningUsing URL-based session ID (e.g., `?PHPSESSID=...`) without disabling from cookies – attacker can embed link.
Concrete fix directions. Pick the one that matches your root cause.
- buildRegenerate session ID immediately after successful authentication, before any session data write.
- buildIn PHP: call `session_regenerate_id(true)` as the first line after password verification, then set user data.
- buildIn Java: call `request.changeSessionId()` before `session.setAttribute(...)` for user object.
- buildIn Node.js: use `req.session.regenerate()` callback to set new data in the fresh session.
- buildAlso regenerate on logout, password change, and privilege escalation (e.g., admin role grant).
- buildDisable URL-based session ID transmission entirely (e.g., `session.use_trans_sid=0` in PHP).
- buildSet `HttpOnly`, `Secure`, `SameSite=Strict` on session cookies to reduce attack surface.
A fix you cannot prove is a guess. Close the loop.
- verifiedAutomate a test that logs in with a pre-set session ID and asserts the cookie changes.
- verifiedRun OWASP ZAP active scan with 'Session Fixation' rule; expect zero alerts.
- verifiedManual test: capture pre-login session cookie, login, check cookie value differs.
- verifiedVerify that after logout, old session ID cannot be reused to access protected resources.
- verifiedCode review: ensure all authentication points (login, OAuth callback, 2FA) call regeneration before any user data write.
- verifiedPenetration test: attempt session fixation with known session ID; should fail to hijack.
Things that make this bug worse or harder to find.
- warningCalling `session_regenerate_id()` after writing user data – the new session inherits the old data.
- warningNot passing `true` to `session_regenerate_id()` in PHP, leaving old session file on disk.
- warningOnly regenerating on first login, ignoring step-up auth like 2FA or admin elevation.
- warningAssuming framework does it for you – always verify with explicit code review.
- warningRelying on session fixation fix as the only protection; also implement CSRF tokens and HTTPS.
- warningTesting only with your own browser – use attacker's pre-set cookie to simulate real attack.
The Session That Wouldn't Die: A Fixation at AcmePay
Timeline
- 09:15Received critical security alert from OWASP ZAP scan: 'Session Fixation' on login endpoint.
- 09:30Reviewed `LoginController.php` – found `session_regenerate_id()` called after `Auth::login()`.
- 09:45Moved `session_regenerate_id(true)` before `Auth::login()`, deployed to staging.
- 10:00Manual test: pre-set session ID still persisted after login. Confused.
- 10:15Discovered Laravel's `Auth::login()` internally calls `session()->regenerate()` with default settings.
- 10:30Checked `config/session.php`: `'regenerate' => false` – oh.
- 10:45Set `'regenerate' => true` and removed custom call. Deployed to production.
- 11:00Re-ran ZAP scan: zero alerts. Verified manually with Burp Suite.
The alert came in as a P1 from our security team: OWASP ZAP had flagged a session fixation vulnerability on the login endpoint. I dropped everything and pulled up the scan report. It showed that after login, the session cookie value remained identical to the one sent before authentication. Classic fixation. I opened the login controller and immediately spotted the problem: `session_regenerate_id(true);` was called after `Auth::login($user);`. That meant the old session data (including the authenticated user) was copied into the new session. I moved the regeneration before the login call, deployed to staging, and tested.
To my surprise, the fix didn't work. The session ID still didn't change after login. I was baffled. I dug into Laravel's authentication internals and discovered that `Auth::login()` internally calls `session()->regenerate()` – but it respects a configuration flag. I checked `config/session.php` and found `'regenerate' => false`. That meant Laravel's own regeneration was disabled, and my explicit call was being overwritten? Actually, no: my call happened before, but then `Auth::login()` didn't regenerate because of the config. So after login, the session ID was still the old one. The real fix was to enable the framework's built-in regeneration and remove my custom call.
I set `'regenerate' => true`, removed the explicit `session_regenerate_id()`, and redeployed. This time, Burp Suite confirmed the session ID changed after login. ZAP scan passed. The lesson: understand your framework's session handling deeply. A configuration flag can silently break security. Also, never trust that moving one line fixes it – always verify with the exact attack payload.
Root cause
Laravel 5.8 configuration `session.regenerate` set to `false`, preventing automatic session ID regeneration after login. Custom `session_regenerate_id()` call was placed after `Auth::login()`, so the new session inherited authenticated data.
The fix
Set `'regenerate' => true` in `config/session.php` and removed the manual `session_regenerate_id()` call from the login controller.
The lesson
Always verify framework-level security settings; a simple config flag can nullify manual fixes. Test with attacker-controlled session ID, not just normal flow.
Most developers know to call `session_regenerate_id()` on login. The mistake is calling it after storing authentication data. In PHP, when you call `session_regenerate_id(false)` (default), it creates a new session ID but copies all existing session data into the new session. If you already set `$_SESSION['user_id'] = $userId;` before regeneration, that data is copied. The old session ID (which the attacker knows) still has a valid file on disk unless you pass `true` to delete the old session. Even with `true`, if the attacker's session ID is still in their cookie and the server hasn't expired the old file, there's a window.
The correct order: start session, verify credentials, immediately call `session_regenerate_id(true)`, then set user data. This ensures the new session starts empty and only then gets the authenticated flag. In frameworks, understand if the framework's auth helper does regeneration internally and whether it respects configuration. Always check the actual execution order with debugger or logging.
Session fixation isn't only about initial login. Any privilege change should trigger a new session ID. Common missed points: two-factor authentication verification, admin impersonation, password change, and role upgrade. If a user logs in with weak privileges, then completes 2FA, and the session ID remains the same, an attacker who obtained that pre-2FA session ID can bypass 2FA.
Similarly, if an admin user is impersonating another user (e.g., 'login as' feature), the session ID must be regenerated after the impersonation to prevent session fixation from the admin's original session. Audit every endpoint where the user's privilege level changes and ensure session regeneration is called.
In Laravel (≤5.8), the `session.regenerate` config default was `false`. Many developers upgraded without checking. In Laravel 6+, it defaults to `true`, but if you migrated from an older version, the config file may still have `false`. Always run `php artisan config:clear` after changes.
In Spring Security, `session-fixation-protection` attribute in `<http>` element can be set to `newSession`, `migrateSession`, or `none`. `migrateSession` copies attributes – only `newSession` creates an empty session. Many apps use `migrateSession` to preserve flash attributes, inadvertently copying authentication data.
In Express with `express-session`, `req.session.regenerate()` is a callback-based API. A common bug: calling `req.session.regenerate()` and then setting `req.session.user` inside the callback, but not waiting for the callback to complete before sending response – leading to race conditions.
A solid test: 1) Make a request to the login page without credentials, capture the session cookie. 2) Make a second request with the same cookie but with credentials. 3) Assert the response sets a new session cookie (different value). 4) Attempt to use the old session cookie to access a protected endpoint – should get 401/redirect. Automate this in your CI with a tool like Cypress or Playwright.
For API-only apps, test with a pre-set session ID in the request header. For example, set `Cookie: session=attacker_session_id` before login, then after login check the `Set-Cookie` header for a new value. Also verify that the old session ID no longer works by making a subsequent request with it.
Session regeneration is necessary but not sufficient. Combine with: 1) HttpOnly and Secure flags to prevent cookie theft. 2) SameSite=Strict to prevent cross-origin requests from including the cookie. 3) Short session timeouts. 4) Bind session to IP or User-Agent (with caution – can break legit users). 5) Implement CSRF tokens to prevent cross-site request forgery. 6) Use a strong random session ID generator (e.g., 128-bit random).
Also, disable URL-based session ID transmission entirely. In PHP, set `session.use_trans_sid = 0` and `session.use_only_cookies = 1`. In Java, configure `SessionTrackingMode` to COOKIE only. This prevents attackers from embedding session ID in links.
Frequently asked questions
Does `session_regenerate_id(true)` in PHP guarantee the old session is deleted?
Yes, passing `true` deletes the old session file from the server. However, the client's cookie with the old session ID may still be present. The key is that the server will no longer accept that old ID because the file is gone. Always use `true`; `false` is almost never what you want.
I'm using Spring Security. How do I enforce a completely new session (not migrate)?
Set `<session-management session-fixation-protection="newSession"/>` in your security XML, or in Java config: `http.sessionManagement().sessionFixation().newSession()`. This creates a new empty session and does not copy any attributes. Be aware that any non-authentication attributes (like a shopping cart) will be lost; you may need to persist them elsewhere.
Can session fixation be exploited over HTTPS?
Yes. Even with HTTPS, the attacker can still set the session ID via a URL parameter (if URL-based transmission is enabled) or via a cookie set by a non-HTTPS page (if the Secure flag is not set). Always use Secure flag on cookies and disable URL-based session ID.
My framework (e.g., Laravel) handles session regeneration automatically. Do I still need to worry?
Yes, because the automatic regeneration can be disabled via config (as in the war story). Always verify the config and also check that regeneration happens on every privilege escalation. Moreover, if you're using custom authentication logic (e.g., manual session writes), you might bypass the framework's regeneration.
Should I regenerate session ID on every request?
No – that would be extremely inefficient and break things like shopping carts. Only regenerate on privilege changes: login, logout, password change, 2FA, role change. Regenerating on every request also defeats the purpose because it gives the attacker too many opportunities to steal a valid session ID.