State, cookies, and sessions

A fictional theater remembers your sign-in while you move from seat selection to your bookings. HTTP requests do not inherently carry a memory of earlier requests. The application builds continuity using identifiers and stored state. That continuity is useful, but it creates a lifecycle that must be managed deliberately.

A cookie is storage with delivery rules

A cookie is a browser-stored value associated with rules for when it is sent. A server can set one in a response; browser scripts can also create some cookies. Cookies can remember language, preferences, or a session identifier. Their presence does not necessarily mean anyone has signed in.

In one common design, the theater issues an unpredictable identifier after authentication. The browser stores it in a cookie. On later eligible requests, the browser sends the identifier, and the service looks up a session record that connects the visit to an account and expiry policy. The identifier should be treated as a credential even though it is not the person’s password.

The session is a relationship, not a magic file

A coat-check ticket is a useful analogy: its number connects the holder to a stored record. The limit is that a digital identifier can be copied, and the service may apply additional checks. Some applications use signed tokens instead of an opaque identifier lookup. A signed value provides integrity under its verification rules; it is not automatically encrypted, current, or easy to revoke.

Application state includes more than the session. A shopping cart, seat reservation, and payment result may live in separate records with different lifetimes. Expiring a session does not necessarily delete a completed booking, and a cookie’s expiry is not the same as the service’s decision to end a session.

PredictThe theater accepts Maya’s current session. Does that mean she may cancel every booking in the database?

No. The session establishes an authenticated context. The service still needs to authorize the specific action on the specific booking. Identity, session validity, and object permissions are separate questions.

Several controls protect different boundaries

Secure restricts cookie delivery to secure connections in ordinary web deployment. HttpOnly prevents access through script cookie APIs; it does not stop the browser attaching the cookie to eligible requests. SameSite limits delivery in certain cross-site contexts, with behavior depending on its setting and the request. None of these attributes alone supplies every protection an application needs.

Domain and path settings also affect cookie delivery. A path is not a robust security boundary between mutually untrusted applications. Keep scope narrow, protect the channel, and let the server enforce access decisions.

End the relationship clearly

For a server-side session, logout should invalidate the session as well as clear the browser value. Idle and absolute expiration address different durations. After a sensitive identity change, rotating the identifier can avoid carrying an older session relationship forward. User-facing messages should explain when authentication is needed again without claiming that all saved account data has disappeared.