What is Session Fixation?

In session fixation, an attacker makes the victim use a session ID already known to the attacker. If the application retains that ID after successful login, the previously anonymous session becomes authenticated. The attacker still knows its key and can access the victim's context.

How does the attack work?

1. The attacker creates or obtains a valid anonymous session ID.
2. The victim receives it through a legacy URL parameter, manipulated subdomain or cookie.
3. The victim logs in and the application upgrades the same session.
4. The attacker sends the known ID and obtains the authenticated context.

PHP code example

Vulnerable: identity is written into the existing session.

session_start();

if (password_verify($_POST['password'], $user['password_hash'])) {
    $_SESSION['user_id'] = $user['id'];
    // The pre-login session ID remains unchanged.
}

Safer: trust changes create a new ID.

session_start();

if (password_verify($_POST['password'], $user['password_hash'])) {
    session_regenerate_id(true);
    $_SESSION['user_id'] = $user['id'];
    $_SESSION['authenticated_at'] = time();
}

Regenerate after login, MFA, privilege elevation and sensitive reauthentication, invalidating the old ID. Prefer framework session APIs over custom implementations.

Required safeguards

• - Transport IDs only in cookies, never URLs, forms or normal logs.
• - Accept only cryptographically random IDs generated by the server.
• - Set Secure, HttpOnly and an appropriate SameSite value.
• - Delete sessions server-side on logout and enforce idle and absolute timeouts.
• - Handle parallel requests without accepting the old ID for an extended grace period.

Fixation versus hijacking

Fixation plants an ID before login. Session hijacking steals an already authenticated session through XSS, malware or insecure transport. Safeguards overlap, but regeneration at trust transitions is what specifically addresses fixation.

Useful open-source tools

OWASP ZAP can record authentication flows and scripts can assert that IDs change at login. mitmproxy supports reproducible pre/post-login comparisons. Both require a deliberate state comparison; business logic is not detected reliably by a generic scanner.