Security
Session fixation and session hijacking: how they work and how to stop them
The difference between fixing a victim's session ID and stealing it, and the specific controls — regeneration, cookie flags, binding — that defeat each.
The short answer
Session fixation is when an attacker gets a victim to authenticate using a session identifier the attacker already knows; it is prevented by issuing a new identifier at login. Session hijacking is when an attacker steals a valid identifier after login — through XSS, malware or network interception — and is mitigated by HttpOnly and Secure cookies, short lifetimes, revocation and, increasingly, binding the session to a device key.
Sources last reviewed .
Fixation
If an application accepts a session ID supplied in a URL or set by a related subdomain, and keeps the same ID when the user logs in, the attacker who planted it is now logged in as the victim. The fix is mechanical: discard any pre-authentication session and issue a fresh identifier at login and every privilege change, and never accept session IDs from URLs (OWASP Session Management Cheat Sheet).
Hijacking
Session cookies stolen by infostealer malware are a common route into accounts today, because a stolen cookie skips the password and the MFA check entirely. Controls reduce the window and the value: HttpOnly blocks script access, Secure blocks plaintext interception, short idle and absolute timeouts limit reuse, and server-side revocation lets a detected compromise be ended. Binding the session to a key held by the device — so a copied cookie is not enough on its own — is the direction the industry is moving.
Detection
Watch for a session used from a sharply different network or client at the same time as its normal use, and give users a list of active sessions they can end. Treat a session that changes characteristics mid-life as a re-authentication trigger rather than a silent block.
In Authreads
How this applies to Authreads
Session revocation and a visible session inventory are Available. Hardware-bound sessions and continuous session evaluation are Planned.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Keep reading
Security
Session management best practices for web applications
Security
Token theft and replay: how bearer tokens are stolen and how to limit the damage
Security
Step-up authentication: asking for more proof only when it matters
Glossary: Session fixation · Session revocation · Idle timeout and absolute expiry
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.