Why a SameSite=None cookie disappears instead of just weakening

SameSite=None is how a site opts a cookie in to being sent on cross-site requests -- an embedded widget, a cross-site payment redirect, a federated login flow all depend on it. It is natural to assume that forgetting the accompanying Secure attribute just makes that cookie a little less protected. It does not: the current SameSite specification requires Secure whenever SameSite=None is set, and Chrome, Firefox, and Safari all enforce that by rejecting the Set-Cookie header entirely. No cookie is stored. The feature it existed for -- the embed staying logged in, the payment flow remembering its session -- simply breaks, with nothing in the response that says why.

The same shape applies to __Host- and __Secure-

Cookie name prefixes are usually just a naming convention. These two are not -- they are a contract the browser itself checks before it will store the cookie at all:

Miss any one of those rules and the browser silently refuses to store the cookie -- again, no error visible anywhere in the response or the page. A server that checks an incoming __Host-session cookie and trusts that its name alone proves it was set by this exact secure origin is relying on the browser having enforced that when the cookie was created; a malformed Set-Cookie header means that guarantee was never established, and the session simply does not exist rather than existing in some weaker form.

Why this reads as a functional bug before it reads as a security one

Both patterns fail the same way: a person hits the flow, the cookie the server thinks it set is never actually present on the next request, and whatever depended on it -- being logged in, a cart surviving a redirect, a CSRF token matching -- silently stops working. It is usually reported as "login is broken on Safari" or "the checkout redirect logs people out" long before anyone connects it to a missing Secure attribute.

Check your own site automatically

The checker on this site sends one real request, reads every Set-Cookie header exactly as Node's HTTP client already splits them (never joined and re-split on commas, which corrupts a cookie carrying an Expires date), and reports exactly which cookie and which rule triggered a rejection -- plus notices for a missing Secure, HttpOnly, or SameSite attribute that weaken a cookie without causing an outright rejection. The request comes from a Node CLI you run yourself against a system you own or are authorised to test; the browser page only renders a report you paste in.

This is evidence from that one response, not a full security assessment -- see the checker and its disclaimer for what it does and doesn't cover.

← Back to the checker