Cookie Security Checker

A Set-Cookie line carries behavior, not just a value

A cookie's name and value are only the first part of the instruction. Secure changes when the browser may send it, HttpOnly changes whether script can read it, SameSite changes cross-site sending, Domain and Path narrow request scope, and expiry attributes decide whether it survives the browser session.

Because those choices depend on what the application is doing, this page separates standards violations from application-dependent cautions. It does not assign a made-up security score to a cookie whose purpose it cannot know.

Secure and HttpOnly solve different problems

Secure limits transmission to secure transport, while HttpOnly prevents JavaScript access through APIs such as document.cookie. An authentication cookie commonly benefits from both. A cookie intentionally read by frontend JavaScript cannot simply be given HttpOnly without changing application behavior, which is why the hardening draft does not add it from a name heuristic alone.

SameSite omission is not a promise of Lax behavior

Modern browsers commonly apply a Lax-like default when SameSite is omitted, but omission is not the same configuration as explicitly sending SameSite=Lax. Compatibility details have changed over time. For a cookie that must be sent cross-site, SameSite=None also requires Secure.

Domain and Path are scope controls, not authentication boundaries

Without Domain, a cookie is host-only. Adding Domain makes it available to matching subdomains as well, which can be too broad for a sensitive cookie. Path narrows when the browser sends a cookie, but the cookie specification explicitly warns against treating Path as a security boundary between applications on the same host.

Prefixes turn part of the cookie name into browser-enforced constraints

The current cookie specification tells user agents to recognize these prefixes case-insensitively. That detail is often missed in server-side linters that only check an exact uppercase spelling.

Partitioned changes storage context, not cookie secrecy

A Partitioned cookie is stored in a partition keyed by top-level site context. The attribute requires Secure, but partitioning does not replace HttpOnly, SameSite decisions, careful Domain scope, or normal server-side authorization. Host-prefixed names can further constrain scope when the deployment can use them.

Max-Age wins when both lifetime attributes are present

When Max-Age and Expires appear together, Max-Age takes precedence. Zero or a negative Max-Age is a deletion instruction rather than a long-lived cookie. Current user-agent guidance also caps very distant expirations to roughly 400 days, so the lifetime check calls out values beyond that boundary instead of inventing a much shorter universal limit.

A hardening draft cannot know your application intent

The draft output only applies mechanical requirements that follow from the existing header: for example, adding Secure when SameSite=None or Partitioned requires it, and repairing the mandatory shape of a recognized cookie prefix. It does not remove Domain from an ordinary cookie, force Path=/, add HttpOnly from a guessed name, or invent SameSite=Lax, because each of those can change real behavior.

The current cookie standard is newer than RFC 6265

RFC 10025, published in 2026, updates HTTP cookie behavior and obsoletes RFC 6265. Browser documentation remains valuable for deployment details such as SameSite=None, localhost handling, Partitioned cookies, and prefix support. If a server framework serializes cookies for you, compare its output with both the current standard and the browsers you support.

References: RFC 10025 and MDN Set-Cookie.

Related Tools