An HTTPS response sets a cookie without Secure

Why it matters

MDN explains that a cookie with Secure is sent to the server only when a request uses the https: scheme, and warns that Secure alone does not protect everything in a cookie.

What to do

1. Look at the finding: it shows the cookie's name and attributes, never its value, and up to ten pages that set it.
2. Add Secure where the cookie is set: in your application, your framework's session settings, your CDN, or the plugin or service that sets it.
3. Keep your site on HTTPS only, so that nothing depends on the cookie over http://.

What we read

We read the Set-Cookie headers on the final response of each crawled HTTPS page, with our own user agent and without logging in. Only each cookie's name and attributes are kept; its value is never stored.

A cookie is reported when it has no Secure attribute. Pages that set the same cookie name are reported together, one finding per name. If another Set-Cookie header cannot be parsed, a separately parsed insecure cookie still provides positive evidence. Without that positive evidence, an incomplete cookie inventory leaves the known name unknown and cannot prove it clean.

Example & evidence

Illustrative example — one response, not a live audit.

https://bakery.example/ answers with:

HTTP/1.1 200 OK
Set-Cookie: basket=[redacted]; Path=/; HttpOnly; SameSite=Lax

The basket cookie has no Secure attribute, so it is reported with this page and the other pages that set it; its value is not recorded.

Set-Cookie: basket=[redacted]; Path=/; Secure; HttpOnly; SameSite=Lax

A possible correction: the same cookie with Secure added.

Confirm & check again

Check for yourself: open your browser's developer tools, reload the page and read the Set-Cookie response headers, or look at the list of cookies, which shows whether each one is Secure.

Check again: Full audit — run a new full audit. With complete captured cookie headers, the finding for this cookie name closes only when no currently crawled HTTPS page sets that name without Secure; a new page setting the same name without Secure keeps it open. An unreadable cookie leaves coverage incomplete, and a different insecure cookie name may create another finding.

Limits & sources

Only the final response of each crawled page is read, without logging in, so cookies set on redirects, by scripts, by other files or after sign-in are not seen. Our crawler sends back the cookies it received, so a server may not set the same cookie twice, and the list of pages is a lower bound. The check does not see whether a browser accepts or sends the cookie.

Confidence: High because the Set-Cookie header is read directly.

Sources

• MDN, Set-Cookie header — explains that a Secure cookie is sent to the server only with requests that use the https: scheme, and warns that Secure does not prevent all access to what a cookie holds. Checked 28 September 2026.

Editorial review: 2 November 2026

Related

• HTTPS pages send no HSTS header — the site does not tell browsers to use HTTPS for it only; this separate check is currently deferred in the audit.