Sessions and cookies

Remembering a login across requests

A session connects multiple requests to an established application context. After Authentication, the application may issue a session identifier that the browser sends with later requests. The server uses it to recognize the session without requiring the full login procedure for every page.

A cookie is one mechanism for carrying state between a browser and a service. Not every cookie is an authentication credential: some store preferences or other application state. A session cookie can nevertheless be as sensitive as the account access it represents. Someone possessing a usable stolen token may not need the original password.

A fictional booking journey

Imagine Noor signs into a training portal and opens a booking page. The browser sends its session cookie, the server recognizes the session, and the application checks whether Noor may view that booking. Recognition and permission are separate steps.

When Noor changes the booking, the application also needs to protect the action against inappropriate cross-site requests and other misuse. Merely observing that a cookie arrived does not establish that Noor intentionally initiated the action. Cross-site request forgery explains that related risk.

Finally, Noor logs out. The meaningful question is whether the session credential is no longer accepted, rather than whether the browser displays a signed-out page. Removing a cookie from one browser and revoking a credential on the server are different operations.

Cookie attributes narrow particular risks

The Secure attribute restricts transmission of a cookie to secure connections. HttpOnly prevents ordinary page scripts from reading it through the cookie API. SameSite controls cookie sending in cross-site contexts. Scope, lifetime, and other settings also influence where the browser sends a cookie.

These protections have limits. HttpOnly does not make malicious script executing inside an application harmless: it may still cause actions in the user's session. SameSite is useful defense in depth but is not a universal replacement for the application's request protections. Choose settings according to the actual flow rather than copying an unexplained configuration.

Session lifetime is an explicit policy

A service can use idle and absolute time limits, refresh behavior, and revocation mechanisms. Those choices affect both convenience and the useful lifetime of a stolen credential. A browser window closing is not a complete security policy, particularly when browsers can restore browsing state.

Consider Noor resetting a password on a second device. Does that revoke the first device's session? The answer depends on implementation and policy. For suspected compromise, responders need to know the real behavior instead of assuming a password change closes every access route. Incident containment connects that question to incident handling.

Inspect the boundary in a training application

Use developer tools on an application you own to identify which cookie carries the session, which protections are set, and when it changes. Avoid copying real session values into chat, screenshots, or shared notes. Record names and behavior rather than secrets.

Test sign-in, logout, expiry, and a documented account-security change with two test browsers. State what each observation demonstrates and what remains unknown. Continue with HTTP and HTTPS for the request model and Authentication for the identity process that begins the session.