Session Security: Cookies, Rotation, Logout and Hijack Resistance

A correct login can still leave a weak session lifecycle. If cookie scope is broader than necessary, a pre-authentication identifier is reused after sign-in, server-side state survives logout, or sensitive events lack a reauthentication boundary, authority can live longer than intended. This lesson uses only a local synthetic fixture; it never touches a real account, credential, session, or external target.

1. Start with the lifecycle problem

The scenario is a synthetic web application with anonymous browsing, sign-in, a privilege-sensitive settings page, and logout. The primary question is not whether a cookie exists. The question is which session handle is valid at each lifecycle event, where authority lives, when rotation is required, and what evidence proves invalidation.

2. The bounded artifact

Your output is Session Lifecycle Security Record v1. Each material row records Lifecycle Event, Session Handle State, Cookie Attributes, Server-side State, Rotation Required, Invalidation Expected, Probe, Observation, Decision, and Residual Risk.

3. What this lesson does not prove

The local fixture is not proof of production security. HTTPS alone does not make every cookie configuration safe. SameSite does not replace every CSRF defense. Deleting a browser cookie does not necessarily invalidate server-side authority. A long random identifier alone does not solve rotation, logout, or reauthentication policy.

4. The session identifier is an opaque reference

In this model the session identifier is a synthetic handle with no business meaning embedded in it. User identity, role, and privilege state remain server-side. Seeing a handle is therefore not evidence of what authority it carries.

5. Browser boundary versus server authority

The browser cookie transports the handle. The authoritative session state in the fixture is SERVER_SESSION_STORE. This distinction matters at logout: browser deletion can remove a local handle while server-side authority remains active unless the corresponding state is invalidated.

6. Cookie attributes are constraints, not a complete proof

The baseline cookie uses Secure, HttpOnly, SameSite=Strict, Path=/, and no Domain. These properties constrain transport, browser access, and scope. They do not replace server-side lifecycle validation.

7. Secure

Secure constrains transmission of the cookie to secure transport. It is important, but it cannot repair a missing rotation or an incomplete logout. The record therefore treats it as one control in a larger lifecycle.

8. HttpOnly

HttpOnly limits direct script access to the cookie value. The lesson does not turn this into a universal compromise-prevention claim. Session authority still has to be validated at the server boundary.

9. SameSite

SameSite affects cross-site cookie sending behavior. The baseline uses Strict to keep the synthetic case explicit. The bounded conclusion is not that SameSite replaces every CSRF control.

10. Domain and Path

Domain and Path shape cookie scope. The baseline follows a __Host- style constraint: no Domain and Path=/. A safe mutation broadens scope so the learner must detect the expansion and decide whether the broader exposure is justified.

11. Anonymous session state

The lifecycle starts with a synthetic anonymous session. That handle represents only anonymous state. Authentication is a privilege-context change, so the old handle must not silently inherit the new authenticated authority.

12. The authentication boundary

After sign-in, the fixture issues a new identifier and makes the pre-authentication handle stale. The required evidence has two sides: the new session works and replay of the old synthetic handle is rejected.

13. Rotation

Rotation binds changed authority to a fresh handle. The rotation_disabled_at_authentication probe deliberately violates that invariant and must produce SESSION_ROTATION_MISSING.

14. Privilege changes

The policy records rotation at authentication and privilege-context changes. This is not a framework tutorial. The point is to make the lifecycle rule explicit and observable in evidence.

15. Server-side invalidation

When a session ends, its server-side state must no longer authorize the session. The fixture marks the session invalid at logout, and a later probe using the same handle must be rejected.

16. Complete logout

Logout has at least two observations in this model: the client no longer presents a usable cookie, and the server-side handle is invalid. If only the client-side deletion occurs, the evidence record must remain incomplete.

17. Replaying a deliberately stale synthetic handle

Negative testing uses only fixture-generated values. A stale pre-authentication or logged-out handle is replayed locally and should be rejected at the server boundary as STALE_SESSION_REJECTED. No real session interception is involved.

18. Hijack resistance without overclaiming

Transport controls, narrow scope, rotation, bounded lifetime, invalidation, and reauthentication can reduce replay and hijack exposure. They do not prove that compromise is impossible. The final record keeps residual risk explicit.

19. Reauthentication boundary

The transfer scenario introduces a synthetic admin console that requires reauthentication before recovery-setting changes. The learner extends the lifecycle record with this risk event without absorbing WebAuthn or recovery-design scope.

20. Separate fact, observation, and inference

Secure=true is a configuration fact. old session rejected is an observed fixture result. “The production system is safe from all session hijacking” is an unsupported inference. The evidence artifact keeps those categories distinct.

21. Positive Evidence

The positive path shows anonymous state, rotation at authentication, a valid authenticated handle, and a bounded sensitive-action path after the required reauthentication condition. Positive evidence is necessary, but never sufficient by itself.

22. Negative Evidence

Negative Evidence must include rejection of the old pre-authentication handle, server rejection after logout, detection that browser-only deletion is not server invalidation, and detection of unjustified cookie-scope expansion.

23. Mutation: disable authentication rotation

Set rotate_on_authentication=false in the synthetic model. Login may still appear successful. The intended failure is that the handle does not change across the authentication boundary, which the evidence gate must detect.

24. Mutation: delete only the browser cookie

Remove the client-side cookie while intentionally leaving the server-side session active. The expected classification is CLIENT_COOKIE_REMOVAL_NOT_SERVER_INVALIDATION. This separates interface cleanup from authority invalidation.

25. Mutation: broaden cookie scope

The fixture can add a broader Domain or weaken the declared scope constraint. This is a defensive configuration audit, not an exploitation exercise. The learner must identify the expansion and justify or reject it.

26. Evidence completeness

If a required record field is removed, the validator marks the artifact incomplete. A green test suite without a traceable decision record is not accepted as complete security evidence.

27. Run the lab

Use lab://SEC-003/SEC003-LAB1. Capture the baseline first, then run each safe local probe. Preserve raw observations and leave the final accountable Decision blank until the evidence is reviewed.

28. Build Session Lifecycle Security Record v1

Create one row per material lifecycle event. Observation must reflect what the fixture actually produced. Decision must remain bounded, and Residual Risk must retain what is not proven.

29. Transfer Case

Transfer Case: a synthetic admin console requires reauthentication before recovery-setting changes. Extend the lifecycle record with the new event, state what happens to the existing session, and name the evidence required before the sensitive action proceeds. Do not redesign WebAuthn.

30. Final assessment standard

Completion requires a lifecycle model, deliberate cookie constraints, positive and negative evidence for rotation and logout invalidation, separation of observation from inference, and an independent changed-context decision.

31. Source and freshness

The official bounded source is OWASP-SESSION. The frozen snapshot was retrieved on 2026-09-02 with review due on 2026-10-02. Query 1 runs on 2026-09-16, inside that window, so the source boundary is not expanded.

32. Human accountability boundary

AI may suggest defensive probes after the learner states the objective or help organize observed outputs. It may not invent unobserved evidence, treat one green run as proof of security, or replace the learner's final risk, policy, or owner decision.