---
{
  "title": "Session fixation",
  "summary": "Session fixation occurs when an attacker can cause a victim to authenticate using a session identifier already known to the attacker.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Session Management",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Session fixation occurs when an attacker can cause a victim to authenticate using a session identifier already known to the attacker. Session identifiers should change at security transitions such as login, with prior identifiers invalidated as appropriate. The surrounding session design must also protect creation, transmission, and termination.

## A practical example

A website creates an anonymous session for browsing and replaces its identifier after successful authentication. It does not attach privileged account state to the unchanged pre-login identifier, and it invalidates the obsolete identifier on the server.

## What to check

Test identifier rotation after login and privilege changes. Review URL-based identifiers, cookie scope, and whether old identifiers continue accessing authenticated state after a transition.

## A common pitfall

Adding strong authentication does not protect a session identifier already shared with an attacker if the server keeps that identifier when granting privileges.

## Think it through

Why rotate the session identifier after login?

**Answer:** It prevents the anonymous identifier known before authentication from becoming a reusable credential for the authenticated account.

## Authentication changes the value of a session

A fictional shop gives an anonymous visitor a session to hold a basket. After login, that session will be able to view addresses and previous orders. If the identifier remains unchanged, anyone who already knows it may inherit those new privileges. The security transition changes what the credential can do even though its characters look the same.

The application should deliberately manage that transition. Generate a new authenticated session identifier and handle the previous identifier according to the session framework's supported lifecycle. Preserve only the anonymous state the product actually needs, such as a basket, rather than copying every pre-login property into the authenticated context.

The same reasoning applies when privileges increase after renewed authentication or an administrative role switch. Not every state change requires identical handling, but the design should identify where the assurance level or authority changes. Avoid accepting session identifiers through unnecessary channels such as URLs, which can expose them through history, logs, or copied links.

## Observe rotation with test identities

In an authorized training service, compare the session identifier before and after a dummy account signs in. Check that the old identifier cannot retrieve the authenticated account state. Also test failed login: a failed attempt should not accidentally create an authenticated session or preserve partially applied privilege changes.

Concurrency needs thought. A browser may have several requests in flight during login, and the framework may need a controlled way to complete the transition. Use supported session mechanisms rather than inventing an identifier migration scheme. Document the desired lifecycle and verify it at the server, because deleting a browser cookie alone does not establish that an earlier credential has lost its authority.

## Related concepts

- [[sessions-and-cookies]]
- [[authentication]]
- [[cookie-security]]