Quiz Entry - updated: 2026.07.14
When must a session ID be renewed (rotated to a fresh value)?
Whenever the user's privilege level changes — most importantly at login, but also at logout, after step-up auth, password change, or any role change. The old ID must be invalidated server-side.
The rule: any time the meaning of the session changes from the server's perspective, issue a new ID.
Critical rotation points:
| Event | Why |
|---|---|
| First login | An anonymous-session ID exists before login (if you serve cookies pre-auth). Without rotation, session fixation wins: attacker primes the victim's browser with a known ID, victim logs in, server upgrades the session but keeps the same ID, attacker takes over. |
| Logout | Don't just clear the client cookie — delete the server-side entry. Otherwise the old ID still works if it was captured. |
| Privilege step-up (e.g. user → admin) | Forces a fresh ID with the new authorisation context. |
| Password change | Existing sessions from elsewhere should be invalidated; a user-initiated password change suggests they suspect compromise. |
| 2FA enabling/disabling | Authorisation context changed. |
Framework helpers (one line each):
- PHP:
session_regenerate_id(true)—truedeletes the old session. - Java Servlet:
request.changeSessionId(). - ASP.NET:
Session.Abandon()then a fresh login. - Django:
login(request, user)(rotates automatically). - Rails:
reset_session.
Tip: The phrase "old session ID must be invalidated" is critical — without server-side invalidation, ID rotation only stops future fixation, not replay of the old captured ID. Both halves are required.