auditing-session-lifecycle-and-fixationlisted

# Auditing session lifecycle and fixation: whether a session is rotated, scoped, and destroyed A session identifier can be perfectly random and still be a bug, because the attack is not guessing it but controlling its lifecycle. If the identifier issued to an anonymous visitor survives unchanged into their authenticated session, an attacker who planted it now holds that session; if logout clears only the client cookie, a captured identifier stays valid; if nothing expires, a stolen identifier lives forever. This audit assumes the identifier is unguessable, that is a separate concern, and asks whether it is rotated at the right moments, invalidated when it should be, timed out, and scoped so only the right party can hold it. You audit it by reading the login, privilege-change, and logout paths and the cookie attributes, against the framework's session defaults. The discipline is checking those defaults first, because the rotation or the attribute is often set centrally, not at the call site. ## When to use - You are reviewing authentication, logout, or session-management code, or the cookie attributes it sets. - You want to know whether a session can be fixated, replayed after logout, or held indefinitely. - The identifier is already assumed unguessable and you are auditing its lifecycle, not its entropy. ## Scope check Exercise session handling only against applications and accounts you own or are authorized to assess; a fixation or replay demonstration rides a real user