Rotate Session IDs on Privilege Change

A session identifier created before login or role elevation must not become the handle for a stronger session without review. If an attacker can set or observe the old identifier, keeping it through elevation can let them use the new authority. OWASP's session guidance recommends renewing session identifiers after privilege changes.

Define the transitions that increase access: anonymous to signed in, ordinary member to admin, support impersonation, or a new tenant grant. The application should issue a fresh identifier and invalidate the old one at the server. Merely changing a role field inside the same session record may not be enough.

Transition test table

A session cookie should use appropriate transport protections, but cookie flags do not replace identifier rotation. If the app uses stateless tokens, define an equivalent way to prevent an old token from gaining new claims. A new role should not be silently applied to every outstanding token.

Owned fixture

Open an anonymous session and save its safe test identifier. Sign in with a synthetic user. Try the old identifier against a protected route and require denial. Repeat after a controlled privilege elevation, then test downgrade and logout. Check the server's session store and response behavior; a changed browser cookie alone does not prove old state was invalidated.

Do not place a real session cookie in logs or screenshots. Record only a hash or test ID and the decisions. Test simultaneous tabs, since one tab may still send the prior identifier. The expected behavior should be clear to the user without preserving the old authority. A session rotation does not revoke a separate API token or provider key; those need their own lifecycle checks.