Secure Cookie Builder

Some of these rules are enforced, not advised

Most cookie guidance is a list of recommendations. Three of the rules this tool checks are not recommendations at all - browsers enforce them by silently discarding the cookie. No console error, no warning, nothing in the network tab to suggest a problem. The cookie is simply never stored.

• SameSite=None without Secure is rejected outright by every current browser.
• __Host- requires Secure, Path=/ and no Domain attribute. Miss any one and the cookie is discarded.
• __Secure- requires Secure. Same silent discard.

The failure mode is what makes these worth a tool. A discarded session cookie does not look like a configuration error - it looks like users being randomly logged out, on some browsers, sometimes. It also tends to work in whatever environment the developer tested, because a valid cookie from an earlier deploy is still sitting in their browser. This tool marks these as critical and says plainly that the cookie will not be set.

The attributes, and when each one is genuinely optional

Secure

The cookie is only ever sent over HTTPS. There is no real case against it on a site served over TLS, and without it any plain HTTP request to the domain - an old link, a stale bookmark, a redirect someone forgot - puts the value on the network in the clear.

HttpOnly

Script cannot read the cookie. For a session cookie this is the control that stops a cross-site scripting bug becoming full account takeover: the injected script can act as the user while the page is open, but it cannot steal the credential and use it later from somewhere else.

There is one legitimate reason to omit it: your own front end has to read the value. A CSRF token the page puts into a request header is the standard example, and it is safe precisely because reading the token is not on its own enough to do anything.

SameSite

Lax is the right default for a session cookie - it is withheld from cross-site subrequests, which is most of CSRF, while still travelling on a top-level navigation so that following a link into your site keeps the visitor logged in. Strict withholds it even then, which is more protective and means arriving from an external link shows a logged-out page.

None is the only value that works cross-site, and it is increasingly unavailable whatever you send: Safari blocks third-party cookies, Firefox partitions them, and Chrome is moving the same way. If you need it, add the Partitioned attribute so the cookie works in partitioned form - and make sure the feature degrades sensibly when there is no cookie at all, because on a growing share of browsers there will not be.

Domain, and the subdomain problem

Leaving Domain out makes the cookie host-only, which is the tighter default. Setting it sends the cookie to every subdomain - including ones another team runs, ones hosted elsewhere, and ones pointing at something abandoned.

The risk is not only reading. A subdomain can also set a cookie that overwrites yours on the parent domain, which is how session fixation through a forgotten subdomain works. __Host- exists specifically to make that impossible, which is why it is the right prefix for anything that authenticates.

Nothing you type here is transmitted

The header is assembled in your browser. The tool also deliberately writes <value> as a placeholder rather than asking for a real cookie value - a session value is a credential and does not belong in a form on any website, including this one.

Frequently asked questions

References

• RFC 6265: HTTP State Management Mechanism
• MDN: Set-Cookie
• OWASP Session Management Cheat Sheet

Related tools