Cybersecurity glossary
What is the __Secure- Cookie Prefix?
Learn what the __Secure- cookie prefix is, how browsers reject non-Secure Set-Cookie attempts under that name, when to choose __Secure- over __Host-, and how to migrate safely.
Definition
The __Secure- cookie prefix is a reserved cookie-name prefix that browsers accept only when the cookie is marked Secure and set from a secure context, ensuring cookies using that name cannot be established over insecure HTTP configurations.
Why __Secure- matters
The Secure attribute is easy to document and easy to omit under deadline pressure. The __Secure- cookie prefix turns that requirement into a browser gate: if Secure is missing, a cookie whose name starts with __Secure- never lands in the jar.
That fail-closed behavior is valuable for HTTPS-only applications, especially when multiple services, gateways, or legacy templates emit Set-Cookie.
How __Secure- works
Pick a __Secure- name
Rename the cookie so it begins with __Secure-, for example __Secure-csrf.
Set Secure in Set-Cookie
Include the Secure attribute and send the header over HTTPS.
Optionally set Domain/Path/SameSite
__Secure- allows Domain and flexible Path, unlike __Host-.
Browser accepts or rejects
Non-Secure attempts are discarded; compliant cookies are stored.
What you gain
Mandatory HTTPS cookie
Prevents accidentally creating a cleartext-eligible cookie under a trusted name.
Flexible scoping
Still allows Domain and non-root Path when product architecture needs them.
Safer migrations
Misconfigured environments break loudly instead of shipping weak cookies.
Works with cross-site needs
Compatible with SameSite=None; Secure designs when third-party context is intentional.
Choosing between prefixes
| If you need... | Choose | Why |
|---|---|---|
| Strongest default for one host session | __Host- | Adds Path=/ and forbids Domain |
| Shared cookie across subdomains | __Secure- | Allows Domain while still requiring Secure |
| Path-scoped cookie under HTTPS | __Secure- | __Host- cannot use Path other than / |
| Maximum restriction always | __Host- when possible | Fewer ways to over-share the cookie |
Adoption checklist
- Identify cookies that must never be set without Secure.
- Rename them with the __Secure- prefix and update all readers.
- Verify HTTPS termination points still forward Set-Cookie intact.
- Keep Domain as narrow as possible even though the prefix allows it.
- Add HttpOnly unless JavaScript truly must read the cookie.
- Set SameSite explicitly for CSRF and embed behavior.
- Prefer upgrading to __Host- later if Domain/Path flexibility becomes unnecessary.
- Include prefix compliance checks in staging smoke tests.
Limits
__Secure- does not make a broad Domain=.example.com cookie safe by itself. It also does not replace HttpOnly, CSRF tokens, or XSS defenses. Think of it as a seatbelt for the Secure attribute—necessary, not sufficient.
The practical takeaway
The __Secure- cookie prefix ensures cookies with that name are only accepted when marked Secure in a secure context. It is the right choice when you want browser-enforced HTTPS cookies but still need Domain or non-/ Path.
Use __Secure- deliberately, keep scope tight, and graduate to __Host- for host-only session cookies whenever your architecture allows.
Related security terms
Frequently asked questions
What is the __Secure- cookie prefix?
It is a cookie name beginning with __Secure-. Browsers store it only if the Secure attribute is present and the cookie is set in a secure context.
How is __Secure- different from just setting Secure?
Anyone can forget Secure on a normal cookie name. With __Secure-, a missing Secure attribute causes the browser to reject the cookie entirely.
When should I use __Secure- instead of __Host-?
Use __Secure- when you need Domain scoping or a Path other than /, but still want browser-enforced Secure. Prefer __Host- when host-only Path=/ is fine.
Does __Secure- allow Domain=.example.com?
Yes. Unlike __Host-, __Secure- permits a Domain attribute. Use that flexibility carefully—shared subdomain cookies expand trust boundaries.
Is SameSite=None compatible with __Secure-?
Yes, and SameSite=None already requires Secure. The prefix adds assurance that Secure cannot be omitted by mistake.
What if a proxy strips Secure from Set-Cookie?
The prefixed cookie will fail to set. That is desirable for security visibility; fix the proxy rather than removing the prefix.
Should CSRF cookies use __Secure-?
If a CSRF cookie must be readable by JavaScript it cannot be HttpOnly, but it can still use __Secure- (and usually SameSite) to keep transport requirements strict.
References
Explore authoritative guidance and frameworks related to __secure- cookie prefix.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.