Trace one session from login to expiry
A login request is only the beginning of a session. The user submits credentials, the server verifies them, creates a new session, and returns a browser cookie. The browser decides whether the attribute combination is acceptable and stores the cookie according to its rules. Later requests may carry the session identifier back to the server, which reads the identifier and decides whether the requested resource is authorized. Each step can fail independently. A browser may reject an attribute combination, the cookie may not match the current host, the session may have expired, or the user may simply lack permission for the resource. Seeing a Set-Cookie header does not prove that the browser stored it, and storage does not prove that a later request will be authorized.
The cookie value should be an unpredictable identifier without business secrets. The server should maintain the identity and session state. If a signed token is used as the cookie value, a signature is not encryption: the holder may still read its contents. Revocation and expiry also have different implementation costs. Do not put every profile field into a long-lived cookie merely to avoid one database lookup. A browser token is a capability carrier. Keep it small, scoped, and possible to invalidate.
Regenerate the session identifier after a successful login and after a privilege increase, then invalidate the old state according to an explicit policy. This reduces session-fixation risk. Non-sensitive work from an anonymous session may be migrated in a controlled way, but the anonymous identifier should not simply become the authenticated identity. Test password verification, session creation, and browser storage together; that is the only reliable way to explain why a user can finish a login flow and still appear unauthenticated.
Anonymous access, successful authentication, sensitive operations, permission changes, logout, and expiry each imply different session actions. Anonymous work may have no authentication cookie. Login creates a new identifier. A sensitive operation may require recent verification. A permission downgrade must change server authorization immediately. Logout revokes the session and removes the browser object. Expiry rejects the old value. Writing these stages down gives every cookie attribute a context instead of treating it as the whole session design.
Multiple tabs share browser cookies, while in-memory account state inside a page can lag behind. One tab can log out while another still displays a name. The next operation must be rejected by the server when the session is revoked; it cannot rely on frontend synchronization. Cross-tab notifications can improve the visual experience, but they are not an authorization guarantee. “The client shows logged in” and “the server permits the operation” are different states, and the latter always wins.
Session rotation also has to account for concurrent requests. An old request may still be running when a new identifier is created. Its response must not write the old cookie back over the new one. The implementation depends on the framework and session store, but login, refresh, and logout should be tested under controlled concurrency. Do not renew every request automatically without a version or revocation rule; a background request that started before logout must not silently establish the session again.
When a browser stores several same-name cookies, the server must not assume that the first value is always the intended one. Use clear names and host scopes, and explicitly remove old variants during a migration. Moving from a broad-domain cookie to a host-only cookie is an improvement only if the old broad value is also revoked. Migration requires a new attribute set, server-side session cleanup, and deletion of historical browser objects.
Prefer a narrow default
Set-Cookie: __Host-session=opaque-value; Path=/; Secure; HttpOnly; SameSite=LaxIn browsers that support the prefix, __Host- requires Secure, a root Path, and no Domain. The cookie is therefore bound to the current host instead of being implicitly extended to every subdomain. If an organization needs cross-subdomain single sign-on, design an explicit authentication flow. Do not widen every session cookie merely to avoid a second login.
Path affects which paths receive a cookie, but it is not a reliable permission boundary. A same-origin page with malicious script may still issue requests or access same-origin resources. A cookie associated with /admin does not isolate that application from every other piece of same-origin code.
Suppose the main application and a documentation site share a parent domain, while the documentation site is hosted by a third party. Setting Domain to the parent expands the cookie’s sending range even when the documentation site has no business need for the session. Review subdomain ownership and hosting relationships, not only current DNS records. An abandoned subdomain can later be claimed, so domain control is not a permanent security fact.
Cross-subdomain SSO can establish a separate host session through an authentication redirect and a verified state exchange. That costs an extra protocol step, but keeps application boundaries clearer. For a small set of internal services, asking the user to sign in again may be safer than sharing one credential across every host. Compare user friction with the actual trust graph; a common parent domain does not prove that all applications deserve the same session authority.
There is also a request-header budget. Each additional large cookie is sent on later requests, and a proxy may reject an oversized header. When login failures are intermittent, compare the cookie names, scopes, and total length on successful and failed requests without printing values. Do not respond by extending every expiry. Remove state that has no purpose or move large business data back to server-side storage. Browser and proxy limits differ, so validate the complete supported path.
HttpOnly limits reads, not every action
HttpOnly prevents page JavaScript from directly reading a cookie, which reduces one way that a token can be copied. It does not make XSS harmless. An injected script can still use the victim’s browser to call authenticated endpoints, read returned page data, or trigger state-changing actions. Treat output encoding, CSP, CSRF defenses, authorization, and session attributes as complementary controls.
Secure limits transmission to a secure connection. Production should use HTTPS. HSTS can help upgrade protocol access, but includeSubDomains should be considered only after every relevant subdomain is ready for HTTPS. An overly broad HSTS policy can make an unprepared service unreachable.
SameSite depends on the real flow
Lax is often a reasonable default for ordinary site navigation. Strict is more restrictive but can change the experience after a user arrives from another site. None is required for some cross-site flows and also requires Secure; browser third-party-cookie policies may impose further limits.
“Same-site” and “same-origin” are not the same relationship. Two different subdomains may be same-site while remaining different origins. SameSite cannot replace same-origin rules or CORS controls. Login callbacks, embedded applications, and payment redirects need tests that follow the real protocol, not just a refresh in one tab.
An identity provider return, a completed payment return, and an embedded frame can all cross a site boundary. Strict may prevent the first request from carrying the expected cookie. Lax does not allow every method and context, and None may still be blocked by browser privacy policy. Test the target browsers and protocol paths instead of treating one local refresh as universal evidence.
Authentication state parameters and CSRF protection remain independent requirements. SameSite is an important layer, but a compromised same-site subdomain may still initiate a same-site request. APIs must validate user intent and authorization, not merely check whether a cookie exists. HttpOnly reduces direct value theft but does not stop injected script from acting through a logged-in browser.
Development hosts and HTTPS also change the result. localhost has special browser behavior that may differ from production. A cookie that can be set during local development does not prove that the production subdomain will accept and send it. Validate the actual combination in a controlled HTTPS preview, and make the environment difference explicit in configuration rather than weakening production security based on arbitrary request headers.
Browser lifetime and server lifetime are different
Max-Age controls how long a browser normally retains a cookie. Server-side expiry and revocation control whether the server still accepts the identifier. On logout, revoke the server session and delete the browser cookie using the matching Domain and Path. Removing the browser object while leaving a copied server credential valid is not enough.
An authenticated session may need an absolute lifetime, an idle lifetime, and a recent-authentication lifetime for sensitive actions. Background polling should not necessarily count as meaningful activity, or an open tab could keep a session alive forever. Define activity on the server and do not trust an arbitrary client claim that the user just acted.
Changing a payment method or exporting private data may require a fresh verification, while ordinary reading may not. The resulting short-lived qualification must be bound to the correct session and purpose; it must not become a permanent administrator switch. When permissions are lowered, authorization must change immediately instead of waiting for cookie expiry.
Logging out one device and logging out every device are different operations. The server can maintain session-level and account-level revocation conditions. A new login creates a new session; it does not reactivate a revoked record. Test a copied old value after expiry, revocation, password change, and permission changes. A device-management name or network address is a useful clue, not an absolute identity proof.
Migrate broad cookies deliberately
An older application may set session on the parent domain and root path, while a new application switches to a host-only cookie with the same name. Browsers can retain both objects and send same-name values on some requests. Server parsing order is not a safe migration strategy, and a subdomain controlled by an attacker may influence the broad name.
Use a clear new name and attribute set, revoke the old server capability, and delete the old object with its original Domain and Path. Sending an expired host-only cookie to the current host does not delete the parent-domain version. A same-name cookie on another path may also remain. Build an inventory of historical names, domains, and paths, then test each logout path.
Old requests can finish after a migration and write an old cookie back. Identify responses that renew sessions and prevent an invalidated version from creating a new session. Use a controlled delayed request: start it, perform logout or migration, then release the old response and verify that the server still rejects the old capability. A frontend cross-tab event can improve visual synchronization but cannot provide this guarantee.
Separate site, origin, and trusted application
Two subdomains may be same-site but different origins. SameSite decisions do not replace the same-origin policy, and a trusted-looking sibling can still issue requests with a broad cookie. Path only controls sending matches; same-origin script can still call other paths. If untrusted content must be isolated, use a separate origin, correct upload types, and execution restrictions.
Cross-subdomain SSO should use a mature protocol with state validation, callback verification, and explicit account binding. It should not pass a session ID through a query parameter to another host. Separate sessions add a flow step but reduce shared credential scope. Decide whether the convenience is worth the trust relationship instead of assuming that a shared company domain is enough.
Verify with controlled HTTPS scenarios
Prepare a root host, a sibling subdomain, and an external origin. Test ordinary navigation, a cross-site callback, and an embedded request if the product supports it. Record three separate observations: whether the browser accepted Set-Cookie, whether a later request sent it, and whether the server authorized that request. A response header alone proves none of the three.
Use browser storage and network inspection without recording values. A real HTTPS preview exposes Secure, Domain, and third-party-policy behavior that local development can hide. When a cookie is blocked, provide a real recovery path such as a fresh login or an independently opened flow; do not weaken the entire application to make an embedded path appear to work.
Do not turn diagnostics into a credential store
Log session creation, rotation, revocation, and authorization failures using an internal correlation ID and necessary timestamps. Never record the complete cookie value. Truncated values, screenshots, browser exports, and network files can still disclose credentials. Use safe, controlled identifiers with limited retention and access. A correctly scoped cookie is still exposed if the same capability is copied into logs.
When diagnosing a session issue, distinguish storage rules, server expiry, revocation, and permission changes instead of reporting that the “cookie disappeared.” Use fake values in tests to prove redaction. Device activity signals can help investigation, but a changed address or browser string is not proof of account takeover and should not automatically trigger a high-impact decision.
Preserve multiple Set-Cookie fields
A login response may set a new session and remove an obsolete cookie at the same time. Set-Cookie is not an ordinary comma-separated list header. If a proxy combines the fields, a browser may no longer interpret them as intended. Expires dates can contain commas, so splitting the combined value is not a reliable repair. Preserve each field using the runtime’s supported cookie-header API and inspect the response after every proxy transformation.
Test two harmless cookies with different names: one sets short-lived state and one removes historical state. Compare the raw delivered fields with browser storage. Printing an internal Headers object may not reveal what the proxy ultimately sent. This test needs no real session token; it verifies multi-value structure and storage behavior without creating another secret-bearing artifact.
Acceptance requires both sides
Check that the cookie appears on the expected host and path, is not readable by page JavaScript when HttpOnly is intended, and is sent only through the intended transport and site contexts. Test cross-site navigation, login callbacks, embedded flows, logout, HTTP entry points, expiry, permission changes, and old-cookie cleanup.
Keep diagnostics tied to lifecycle events rather than copied credentials. A complete session contract explains why each attribute exists, which workflow it affects, and what failure should appear when it is missing. Copying one Set-Cookie line from the internet gives a form, not a trustworthy boundary.
Make fixation and rotation observable
Session fixation is not only a login bug. It is a failure to establish a new server capability when the security context changes. Before authentication, a browser may have an anonymous identifier for a cart or a draft. After authentication, the server should create a different identifier and migrate only the state that the product explicitly allows. The old identifier must no longer authenticate the account. The same rule applies when a user becomes an administrator, accepts an invitation, or completes a step-up verification.
Rotation needs an observable event model. Record that an old session was replaced, that a new session was issued, and that the old capability was revoked. Keep the internal correlation ID separate from the cookie value. If an investigation later finds two requests using different identifiers for the same account, the event trail should explain whether this was a normal rotation, a second device, a retry, or an unexpected replay. Do not solve this by logging both raw values; that creates a credential archive.
Background refresh complicates the picture. A request that started before rotation may return after the new cookie was installed. Responses that set a cookie should carry a version or otherwise check that the session is still current. A stale response must not undo logout, downgrade a privilege, or restore a broad-domain cookie. Test this with a delayed response and a barrier in the session store. The important assertion is server capability, not only the final value visible in browser storage.
Account for proxies and cache layers
Cookie behavior can change between the application and the browser. A reverse proxy may rewrite a domain, strip a security attribute, combine headers, or cache a response that should have been private. CDN and gateway rules should be part of the session threat model. Compare the origin response with the final response delivered over the public route. An application unit test that inspects only its own response object cannot certify the proxy path.
Responses that set or clear authentication cookies should have deliberate cache behavior. A cached login response can expose one user’s headers to another request, while a cached logout response can make a browser appear to have signed out without changing the server session. Use explicit cache controls and test a shared edge with two controlled clients. Never use a real account or a real session value in a cache diagnostic. The test needs only harmless fake cookies and separate correlation labels.
Header size is an operational boundary as well as a security concern. A product can remain correct in a local browser and fail behind a load balancer once several feature cookies accumulate. Measure the complete request and response headers at each hop, including locale, experiment, consent, and authentication state. Keep a budget for the session itself, reject unnecessary duplication, and document which component owns deletion. A silent proxy truncation is not a browser compatibility issue; it is a broken contract between layers.
Define authorization independently
The presence of a valid-looking session cookie is not permission to perform every action. The server should load the current account, resource, and policy before authorizing a request. A role change, account suspension, deleted organization membership, or payment hold can make an otherwise valid session insufficient. This is why client state and server authorization must be tested separately. A UI that hides a button is useful ergonomics, not an access control.
Do not encode a permanent authorization decision only in a long-lived cookie. If a short-lived claim is used for performance, bound it to a server-recognized session version and refresh it when the account policy changes. Sensitive operations should use the current policy and, where appropriate, recent authentication. A cookie attribute cannot repair an endpoint that fails to check ownership or role membership.
Build a browser matrix instead of a browser myth
Cookie support varies by browser version, privacy mode, embedded context, and user settings. Test the browsers that the product actually supports, including a normal window, a private window, and a restricted third-party-cookie configuration when the application embeds another origin. Include redirects from an external site, top-level navigation, POST callbacks where relevant, and a second tab that has stale UI. Record expected behavior per flow rather than declaring that one global SameSite setting is universally correct.
The test record should distinguish accepted, stored, sent, and authorized. These are four different checkpoints. For an accepted but unsent cookie, inspect domain, path, Secure, SameSite, and browser policy. For a sent but rejected session, inspect server expiry, revocation, account status, and resource authorization. For an authorized request that displays stale UI, inspect frontend synchronization. This vocabulary makes failures actionable and prevents a browser symptom from being mistaken for a single root cause.
Review the contract during every migration
Cookie attributes are easy to add and difficult to remove safely. Before changing a name, domain, path, or lifetime, inventory all applications that set or clear the old object. Search server code, edge rules, client utilities, test fixtures, and operational runbooks. Document the transition window, the expected old-session rejection behavior, and the rollback plan. A rollback that merely restores the old setter may reintroduce a broad capability after some clients have already migrated.
During rollout, use a new name when ambiguity is possible. Accepting both old and new names can be necessary for a short transition, but each accepted form needs an explicit expiry and revocation rule. Measure how many requests still rely on the old object without recording its value. Remove the compatibility path once the population is low enough and verify that an old browser object cannot recreate an authenticated server session.
References: Set-Cookie, OWASP Session Management.