Cookies are attached to requests according to browser rules, not according to the server component that originally set them. A broad Domain or Path can expose state to unrelated routes or subdomains, while missing transport and script restrictions enlarge the damage from other failures.

Cookie scope begins with host-only versus Domain scope. Path selects request paths but is not authorization. Secure restricts transport without encrypting storage. SameSite controls cross-site context; None needs Secure in modern browsers. HttpOnly blocks document.cookie access but the browser still sends cookies. Supporting browsers require Secure, no Domain and Path=/ for __Host-. Deletion matches the name and domain/path scope, meets prefix and secure-origin requirements, and is separate from server session invalidation. Static-site checks include headers and browser storage.
Review the dimensions together, but keep their roles separate: where cookies are sent, who can read them through JavaScript, and which stored identity a deletion targets.

When Domain is omitted, the cookie is scoped to the host that set it. Adding Domain=example.test allows it to be sent to eligible subdomains too. Use the broader form only when multiple hosts genuinely share the same application and trust boundary.

Inspect the response without printing real cookie values into logs. Header names are case-insensitive, so redaction must work for lowercase HTTP/2-style names too:

curl -sS -D - -o /dev/null https://app.example.test/login \
  | awk '
      tolower($0) ~ /^set-cookie:/ {
        sub(/^[^:]*:[^;]*/, "Set-Cookie: [value redacted]")
        print
      }
    '

Review the attributes together

  • Secure restricts cookie transmission to secure transport, normally HTTPS; it does not encrypt the stored value.
  • HttpOnly prevents JavaScript access through document.cookie; it does not stop the browser from sending the cookie.
  • SameSite influences cross-site requests and must match the application’s navigation or embedding needs.
  • Path controls when a cookie is sent, but it is not an authorization boundary between applications on the same host.

A cookie using SameSite=None also needs Secure in modern browsers. Avoid copying that pair into applications that do not require cross-site use.

Same-site is broader than same-origin: sibling HTTPS subdomains can be same-site while remaining different origins. SameSite therefore cannot replace the host boundary or the application’s CSRF defenses. Cookies are also not isolated by port, even with the __Host- prefix.

Use prefixes when their constraints fit

Cookie name prefixes such as __Secure- and __Host- let supporting browsers enforce additional requirements. A __Host- cookie must use Secure, omit Domain, and use Path=/, which makes the host-only intention explicit.

Test deletion with the same scope

Delete the same cookie name and domain/path scope using Max-Age=0 or a past Expires value; not every attribute is part of its storage identity. Meet the prefix and secure-origin requirements when sending the deletion. Preserve whether Domain was omitted: expire a host-only cookie without adding Domain, and specify its original Path. The current 6265bis draft includes the host-only flag in storage identity, so matching only the displayed domain string is insufficient as a portable deletion recipe. Verify deletion in the target browsers. A logout that clears only one scope can leave another active, and server-side sessions or tokens may also need invalidation.

A genuinely static documentation site normally has no reason to set application cookies. Check representative public responses for Set-Cookie and inspect browser storage after navigation, including any third-party scripts. A curl header check alone cannot detect JavaScript-set cookies or other browser storage; avoid adding storage the site does not need.

Sources