Web Security / Basic: web trust and identity contracts / Lesson 4

Sessions, cookies, and browser state

Design session lifetime and cookie scope as separate controls, with explicit rotation, invalidation, and browser assumptions.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Explain Secure, HttpOnly, SameSite, and host/path scope.
Separate a cookie’s presence from a valid authorized session.

A cookie transports state rather than proving permission

A session connects a validated sign-in to later requests under a defined lifetime and revocation model. A cookie is one way the browser transports an identifier or other state; its presence does not prove that the server still accepts the session. Use supported session middleware with an unpredictable identifier and appropriate storage. Do not design a real session by copying the public marker in this lesson. Authentication, session validation, and operation authorization remain distinct. A bearer token has different storage and revocation considerations and is not automatically safer merely because it is not called a cookie.

Read a header without installing a policy

The header is a fictional same-site session-cookie example with no Domain attribute and a root Path. Its public value is intentionally not a credential. The Lax choice is illustrative, not a universal recommendation; cross-site requirements need their own reviewed design. SameSite=None has additional secure-context requirements in current browser guidance, while browser defaults and compatibility can evolve. The header does not create server storage, entropy, rotation, or logout behavior. A real implementation should let maintained framework APIs generate correctly scoped headers and should avoid sharing a broad domain cookie without a justified need.

http A non-operational synthetic Set-Cookie header

Set-Cookie: __Host-lab_session=public-demo-marker; Path=/; Secure; HttpOnly; SameSite=Lax

The marker must never be used as a real session value. The example explains attributes only and is not sent to a browser or server. Supported __Host- enforcement requires Secure, Path=/, and no Domain under the documented browser contract.

Check the declared header shape locally

The standard-library parser below reads the synthetic cookie string and checks three declared attributes. It does not simulate browser prefix enforcement, site computation, storage, or HTTP delivery. This distinction matters because a parser accepting text does not establish a secure deployed session. Keep server expiry, idle and absolute lifetime, rotation after authentication or privilege changes, and revocation behavior in separate integration evidence. Browser deletion alone does not necessarily invalidate other server sessions. Use controlled fake identities to verify the approved lifecycle, never real credentials or a configured account for classroom diagnosis.

python A complete offline cookie-parser check

from http.cookies import SimpleCookie

jar = SimpleCookie()
jar.load("__Host-lab_session=public-demo-marker; Path=/; Secure; HttpOnly; SameSite=Lax")
cookie = jar["__Host-lab_session"]
assert cookie["path"] == "/"
assert cookie["secure"] is True
assert cookie["httponly"] is True

Runs with Python’s standard library and an invented public marker. Passing assertions verify only the parsed attribute values. No browser, session database, HTTP request, login, or real credential is involved.

Verify lifecycle and sensitive response handling

Review creation, renewal, privilege changes, logout, factor replacement, and compromise response as a connected session lifecycle. Expired or revoked sessions should not retain protected capability merely because a client still sends an old value. Sensitive responses need appropriate caching policy and must not expose tokens through URLs, referrers, or logs. Use trusted framework mechanisms for token verification and cryptographic operations rather than parsing and trusting a signed-looking string. Test legitimate continuity and intentional invalidation together. The documented cookie baseline is a starting point for review, not proof that a particular application’s session system is secure.

Common errors and fixes

HttpOnly is treated as a CSRF defense

Why it happens: Script readability is confused with browser credential sending.
How to fix it: Review request authenticity under the actual session model.
Prevent it next time: Document the separate purpose of each cookie attribute.

Deleting the browser cookie is called full revocation

Why it happens: Client storage and server acceptance are conflated.
How to fix it: Verify the approved server-side invalidation behavior.
Prevent it next time: Test old-session rejection after lifecycle changes.

A demo marker becomes a real session id

Why it happens: Illustrative syntax is mistaken for secure identifier generation.
How to fix it: Use maintained unpredictable session generation and storage.
Prevent it next time: Keep synthetic examples isolated from production configuration.

Check your understanding

1. Can a script still initiate an action when a cookie is HttpOnly?

Show worked solution

HttpOnly restricts reading that cookie through script APIs; it does not eliminate every action executed in the authenticated browser context. Authorization, XSS prevention, and CSRF defenses remain separate requirements.

2. Why does a parser test not prove __Host- enforcement?