Authentication Foundations: Sessions, Cookies, and Trust Boundaries

Identify the trust boundary

The browser is controlled by the person using it. Hidden form fields, local storage flags, and a disabled button can all be changed. The server must independently verify identity and permission for each protected operation. Treat a client-supplied user ID as a requested resource selector, not as proof that the requester owns that identity.

Authentication proves an identity through a credential or an identity provider. A session lets subsequent requests refer to that proof without resending the primary credential. Authorization is a separate decision about the operation and resource. Keeping these responsibilities separate makes it possible to change login methods without accidentally changing access policy.

Establish and rotate a session

For a traditional browser application, a random opaque session identifier can refer to server-side session state. Generate it with a cryptographically secure source, associate it with the authenticated principal, and rotate it after login and privilege changes. Rotation prevents a session identifier established before authentication from becoming an attacker-controlled authenticated session.

Set a cookie's Secure flag when using HTTPS and HttpOnly when JavaScript does not need access to it. Use an appropriate SameSite policy and a narrow path/domain scope. HttpOnly reduces direct token theft by JavaScript, but it does not stop an injected script from issuing requests with the user's cookies. Cookie flags complement output encoding and content security controls; they do not replace them.

Expiration and revocation are operational features

Define idle and absolute lifetimes. Logout should invalidate the session, not merely remove a visible profile panel. Password changes or suspected credential theft may require revoking other sessions. If a token is self-contained, a signed claim can remain valid until expiration unless the design includes a revocation mechanism. A signature prevents undetected modification; it does not hide the token's payload.

Never store raw passwords. Use a maintained password-hashing implementation with an appropriate adaptive algorithm and parameters; do not invent a hash construction from general-purpose digest functions. Protect login and recovery flows against abuse with bounded attempts and appropriate rate limits, without leaking whether a particular account exists.

Protect browser request intent

Cookies are sent automatically under browser rules, so authenticated state-changing endpoints need a CSRF strategy. SameSite helps, but evaluate the actual cross-site flows, methods, and deployment topology. A CSRF token and Origin checks are common defenses. Do not perform state changes on GET requests.

Test login followed by session rotation, expiration during a request, logout from two tabs, and rejection of a cross-site state-changing request. Keep credentials, cookies, recovery tokens, and session IDs out of application logs. An authentication system should be debuggable using event types and correlation IDs without exposing the secrets that grant access.