HTTP Cookie Debugging: Domain, Path, SameSite, Secure, Expiry

HTTP cookie debugging works best when you separate three browser decisions: whether the response was allowed to set a cookie, whether the browser stored it with the intended scope, and whether a later request matched that scope closely enough to send it. Capture evidence for each decision before changing Domain, Path, SameSite, Secure, expiry, CORS, or application logic.

Use approved test accounts and redact cookie values, session identifiers, tokens, personal data, and full authentication responses. Names, attribute summaries, timestamps, request destinations, and yes-or-no storage evidence are usually enough to diagnose the fault without exposing a reusable secret.

Separate Receipt Storage And Sending

A visible Set-Cookie header does not prove persistence, and a stored cookie does not prove it will be sent to every request. Start with one reproducible workflow and label the failing transition: response to storage, storage to request, or application interpretation after the request arrives.

Record the page URL, response URL, request method, response status, redirect chain, top-level site, iframe status, and whether JavaScript or navigation initiated the request. This context determines which browser rules apply and prevents unrelated attribute changes.

Capture The Exact Set-Cookie Response

Inspect the network response that should create or update the cookie. Record the cookie name and each attribute without copying the value. Confirm Set-Cookie appears on the final relevant response, not only on an intermediate redirect or a different environment host.

Look for malformed dates, duplicate attributes, an invalid Domain, an unexpected default Path, SameSite=None without Secure, or multiple Set-Cookie fields collapsed by a proxy. Browser developer tools often expose a rejection reason; treat that visible reason as the first authoritative clue.

Check Whether The Browser Stored It

Open the browser’s cookie storage view immediately after the response. Filter by the response host and cookie name. Compare the stored Domain, Path, SameSite, Secure, HttpOnly, expiration, partition information, and creation time with the server’s intended contract.

The RFC 6265 storage model allows user agents to reject or evict cookies under defined and implementation-specific conditions. Private browsing, user settings, extension policies, storage limits, and third-party restrictions can therefore matter even when syntax looks valid.

Verify Host And Domain Scope

A cookie without Domain is host-only and returns only to the host that set it. A valid Domain attribute can make it available to matching subdomains, which broadens scope. Compare the response host, stored domain, and next request host character by character.

Do not add Domain merely to make a test pass. Use the narrowest scope that supports the architecture. Test the apex host, intended subdomain, sibling subdomain, and a lookalike host. Leading dots do not create a separate modern behavior, so document the normalized domain rather than relying on that notation.

Verify Path Matching

Compare the cookie’s stored Path with the outbound request path. A Path of /account can match /account and deeper paths but not an unrelated /api route. If Path was omitted, the browser derives a default from the response URL, which may be narrower than the application expected.

Path controls sending scope but is not a security boundary between applications on the same host. Set an explicit Path when a stable application contract needs it. Test exact path, child path, sibling path, and root requests to expose accidental defaults.

Classify Same-Site And Cross-Site Context

SameSite uses site context, not simply same-origin. Determine the top-level site, request site, navigation type, HTTP method, iframe state, and whether the flow is same-site or cross-site. Then compare the stored SameSite value with the workflow.

The MDN Set-Cookie reference documents Strict, Lax, and None behavior and notes that SameSite=None requires Secure. Avoid selecting None by default; use it only when the cross-site use case is intentional and protected.

Check Secure And HttpOnly

Secure restricts transmission to secure channels, with browser-specific localhost treatment. Confirm production and preview requests use HTTPS from the first hop and do not rely on an insecure redirect. Inspect mixed environments carefully because a cookie that works on localhost may fail on a shared HTTP test host.

HttpOnly prevents JavaScript access but does not prevent the browser from attaching the cookie to eligible network requests. An absent value in document.cookie can therefore be correct. Verify HttpOnly sessions in the Network panel and server logs rather than removing the protection for debugging convenience.

Align Fetch Credentials And CORS

For fetch requests, record the credentials mode. The Fetch Standard defines omit, same-origin, and include; the mode affects sending credentials and whether response credentials are used. A cross-origin request that expects cookies normally needs an intentional include mode plus a compatible server policy.

Coordinate this with the CORS debugging workflow. Credentialed CORS requires an explicit allowed origin and credentials permission. CORS success still does not override Domain, Path, SameSite, Secure, or browser privacy rules.

Resolve Duplicate Cookie Names

Browsers can store cookies with the same name under different Domain or Path scopes. The outbound Cookie header can then contain more than one matching name, and server frameworks may choose one according to parsing behavior the application did not expect.

Inspect every stored row for that name and compare scope, creation time, and expiry. Rename cookies when applications share a host but need independent state, or delete obsolete variants with their exact original scope. Do not assume setting one replacement row removes all namesakes.

Verify Expiry And Clock Behavior

Compare Max-Age, Expires, the response Date header, browser storage expiry, server time, and client time. RFC 6265 gives Max-Age precedence when both are present. A zero or negative Max-Age expires the cookie, while omission of both creates session behavior controlled by the user agent.

Do not promise persistence until the displayed expiry and a restart test support it. Browser session restoration, user deletion, privacy controls, or storage pressure can alter practical retention. For security cookies, choose a lifetime tied to the risk and server-side session policy rather than an arbitrary distant date.

Delete With Matching Scope

Logout and cleanup responses must target the same cookie name, Domain, and Path used when the cookie was created, then set Max-Age=0 or a past Expires value. A deletion at Path=/ does not necessarily remove a namesake stored at /account, and changing Domain can leave the host-only row intact.

After deletion, inspect storage and the next request. Also revoke the server-side session or token where applicable. The password reset security QA guide explains why browser cleanup alone is not equivalent to invalidating authenticated state.

Inspect Redirects Proxies And Error Paths

Map every layer that can set, strip, rewrite, or duplicate cookie headers: application framework, authentication middleware, reverse proxy, CDN, gateway, and hosting platform. Inspect redirects and error responses because cookies may be created or cleared there rather than on the expected success response.

Compare approved direct-origin and public-edge responses in a controlled environment. Verify forwarded scheme and host handling, header preservation, cache bypass for private responses, and consistent attributes across success, validation failure, unauthorized, and logout paths.

Protect Sensitive Evidence

Never paste cookie values, session identifiers, password-reset tokens, authorization headers, private response bodies, or full browser storage exports into tickets. Use redacted names, scope attributes, timestamps, and request eligibility results. Restrict access to any necessary diagnostic capture and delete it under the retention policy.

Use synthetic accounts and isolated environments where possible. If a real secret is exposed during debugging, rotate or revoke it rather than relying on message deletion. Do not weaken Secure, HttpOnly, or SameSite in production simply to make inspection easier.

Build A Regression Matrix

Test receipt, storage, and sending across approved hosts, paths, HTTPS states, same-site and cross-site contexts, fetch credentials modes, redirects, expiry, logout, and duplicate-name cleanup. Include positive and negative cases so permissive fixes cannot pass unnoticed.

Assertions should verify the response attributes, stored scope, outbound Cookie presence without logging its value, server session result, and deletion behavior. Pair browser automation with the Fetch API error handling guide so HTTP and parsing failures are not misreported as cookie faults.

Define Release Evidence

A cookie fix is ready when the intended response sets one correctly scoped cookie, the browser stores it, eligible requests send it, ineligible contexts do not, expiry is correct, logout removes the matching scope and revokes server state, and redirects or proxies do not alter the contract.

Block release for unexplained rejection messages, broad Domain scope, unnecessary SameSite=None, insecure transport, duplicate names, mismatched deletion, exposed secrets, or missing negative tests. The Full Stack Web Development course can build the browser, API, authentication, and deployment skills behind this evidence-driven workflow.

FAQ

Why is Set-Cookie visible but the cookie is not stored?

Inspect the browser’s rejection reason and compare Domain, SameSite, Secure, expiry, credentials mode, and privacy context. A response header alone does not prove the storage gate passed.

Why does logout leave a cookie behind?

Deletion must use the same name, Domain, and Path as the stored cookie. Check for duplicate names under other scopes and revoke the server-side session too.

Does HttpOnly stop a cookie from being sent with fetch?

No. HttpOnly blocks JavaScript access to the value, but the browser can still attach the cookie to eligible requests according to scope, SameSite, Secure, credentials mode, and other policies.