CEH · M11

Session tokens: authority after login

Websites often maintain login state with a session identifier. Its transport, storage and invalidation need deliberate protection alongside the password.

After this lesson, you can
  • Explain why a session token can carry a user’s authority.
  • Distinguish Secure, HttpOnly and server-side invalidation.

Prerequisites: Identity and privilege: what can you do after login?

Possession of a token differs from entering a password

After login, a server may place a session identifier in a cookie. Later requests carry it, allowing the server to recover identity and state. If possession is sufficient, someone holding a valid token may use that session without re-entering the password.

Do not place real tokens in public screenshots, URLs or debugging records. This unit uses fictional labels to describe the lifecycle and displays or collects no real cookies.

Further reading: OWASP: Session Management Cheat Sheet

Each protection addresses a different risk

Secure restricts cookie transmission to secure contexts. HttpOnly prevents ordinary page scripts from reading it through document.cookie, but does not stop every XSS action. SameSite constrains some cross-site transmission and does not replace request authorization or a complete CSRF defense.

Identifier renewal after login or privilege changes, idle and absolute timeouts, logout and revocation belong to the lifecycle. Deleting a browser cookie does not automatically invalidate the old identifier on the server; verify that it is no longer accepted.

Further reading: OWASP: Session Management Cheat Sheet

Example: an old identifier survives logout

A synthetic flow logs in with S1, then removes the browser cookie on logout while the server still considers S1 valid.

The browser no longer sending S1 differs from the server rejecting S1. If S1 was copied, deleting the cookie alone does not revoke that copy.

Conclusion: Logout acceptance should include rejection of the old session.

Tabletop exercise: draw session states

Use paper and fictional identifiers S1 and S2. Do not read real cookies.

  1. Draw logged out, S1 active, logout requested and S1 invalid.
  2. Add a branch renewing the identifier to S2 after a privilege change.
  3. Mark the step that needs server-side evidence.

Expected result

Invalidation needs evidence that the server rejects the old identifier; returning to a login screen is insufficient.

Check your work

Does HttpOnly guarantee that injected scripts cannot send any requests as the user?

Finish and clean up

Keep the state diagram. No real sessions need clearing.

Q&A · Check your reasoning

Choose an answer and confidence, then read every explanation. Answers stay in this browser.

ceh-m11-session-q1 · Original practice

Does seeing the logout screen prove the old token is invalid?

Does seeing the logout screen prove the old token is invalid?
ceh-m11-session-q2 · Original practice

What does HttpOnly primarily restrict?

What does HttpOnly primarily restrict?

Connect the next idea

Terms: Session·Authorization

Sources & scope

These sources support the technical principles. Examples, questions and exercises are original to this series.