Check session changes at login and elevation
Build a session-transition test record for login, privilege elevation, and logout. Check that an old session identifier cannot inherit new authority.
Session fixation concerns the authority attached to a session identifier across an authentication change. The useful question is not simply whether a cookie changed. It is whether an identifier from an earlier state can still reach the newly authenticated account.
OWASP recommends session identifier renewal after privilege changes. The test record here applies that principle to a controlled account lifecycle. Use only accounts and environments included in the written test scope.
Name the session states
Start with two independent browser contexts. Context A completes the legitimate journey. Context B represents a holder of the earlier identifier. Keep both contexts on synthetic accounts, and keep raw cookie values out of logs and screenshots.
| Transition in A | Observation in A | Required check in B |
|---|---|---|
| Anonymous to signed in | New authenticated session state | Earlier identifier cannot read account data |
| Member to elevated action | Recorded step-up result | Earlier authority cannot perform the elevated action |
| Password recovery | Defined session replacement behavior | Prior sessions follow the documented invalidation policy |
| Logout | Server session ended | Retained identifier cannot restore the session |
For each row, record a harmless protected request and its expected result. A redirected page alone may conceal an API that still accepts the old state.
Distinguish rotation from invalidation
Compare opaque fingerprints of identifiers rather than exposing their contents. A new fingerprint shows a change, but the old identifier must also lose the authority that the policy says it should lose. Check that result against the server.
Some systems retain narrowly scoped anonymous state, such as a shopping preference, while replacing authentication state. Document the separation. Do not require the deletion of unrelated preferences merely to make all cookies look different.
Concurrent requests need attention. A request started before login may complete afterward. Record whether it can refresh the old session or overwrite the new cookie. Reproduce timing with a controlled test harness rather than an unbounded request flood.
Keep a repeatable regression
In an owned test harness, create an anonymous session in context B and retain its identifier only in process memory. Copy that same pre-login identifier into context A, then sign A in with a synthetic account. Call a protected API from both contexts. A must work under the new authenticated state; B must not gain account access with the retained identifier. Repeat after step-up and logout with the policy's expected old-state result. Store only identifier fingerprints and response decisions in the test record, never raw cookies. The exact cookie-copy method depends on the session implementation.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.