Skip to content
>_ITDITDWeb Security Platform

Glossary

#session fixation#vulnerability#web

What is session fixation — making a victim log in with an ID the attacker already knows

Session fixation makes a victim use a session ID the attacker planted, then impersonates them once they log in with it. How it works, and the real defense — regenerate the session ID on login, never accept an ID from the URL, set cookie flags — explained defensively.

Published 2026-06-11 Updated 2026-06-11 3 min read

"The victim logs in with an ID the attacker prepared" — that's session fixation. Here's how it works and how to reliably prevent it (no attack steps).

Why it works

The crux is a design where the session ID doesn't change across login. If it doesn't, an ID the attacker knew before login still works as "authenticated" after login.

1) Attacker gets the victim to use a known session ID (via a link, etc.)
↓ the victim logs in with that ID still set
2) The ID isn't regenerated = the same ID becomes "authenticated"
↓ the attacker knew that ID all along
3) Accessing with the same ID = impersonating the victim
If the ID doesn't change at login, an ID the attacker knew beforehand becomes authenticated as-is.

It can pair with CSRF or XSS, but the essence of fixation itself is a single thing: the ID wasn't regenerated at login.

Defense: regenerate the ID at login

1

Regenerate the session ID on successful login (most important)

The instant auth succeeds, discard the old ID and issue a new session ID (most frameworks' session regenerate/renew). Any pre-planted ID is invalidated immediately. Regenerate on privilege escalation (e.g. becoming admin) too.
2

Don't accept session IDs via the URL

Handle the session ID in a cookie and ignore an ID specified in a URL parameter. Close the path an attacker uses to make a victim adopt a 'fixed' ID.
3

Harden cookie flags

Set session cookies HttpOnly (JS can't read), Secure (HTTPS only), and SameSite (curbs cross-site sending). Weakens related hijacking paths together.
4

Expire sessions sensibly

Expire on idle timeout, logout, and password change so a fixed ID can't live on indefinitely.

This site's view: don't disable the framework's 'regenerate'

Session fixation is mostly shut down by a single move — regenerating the ID at login — not by elaborate custom code. The key is to not accidentally disable or forget to call the mechanism your framework already provides. Riding a proven implementation's safe defaults beats hand-rolling your own session management. On this site we hold to "don't build auth/key handling yourself; don't disable the safe defaults." As with IDOR, authentication/authorization should be enforced by a mechanism on every request.

FAQ

QHow is fixation different from session hijacking?
A

Hijacking steals someone's already-issued session ID. Fixation is the reverse: the attacker gets the victim to use an ID the attacker already knows, then waits for the victim to log in with it. It doesn't steal — it gets an attacker-known ID authenticated.

QWhat's the top defense?
A

Regenerate the session ID at the moment of login. Most frameworks/session libraries have this (session regenerate/renew): on successful auth, discard the old ID and issue a new one. That alone invalidates any ID the attacker planted in advance. Regenerate on privilege changes (e.g. becoming admin) too.

QWhy is putting a session ID in the URL dangerous?
A

An ID in the URL leaks easily via shared links, the Referer header, logs, and browser history — a way for an attacker to get the victim to use a 'fixed' ID. Handle session IDs in cookies, not URL parameters, and don't accept an ID specified via the URL.