Cybersecurity glossary

What is a Secure Cookie?

Learn what the Secure cookie attribute does, why it blocks cookie sending over HTTP, how it pairs with HSTS and cookie prefixes, and how to deploy Secure cookies safely.

Web platform securityUpdated July 23, 2026
Also known asSecure attributeSecure flagHTTPS-only cookie

Definition

A Secure cookie is a cookie marked with the Secure attribute so browsers only send it on encrypted HTTPS (and other secure) requests, preventing transmission over cleartext HTTP where network attackers could read or inject cookie values.

Why Secure cookies matter

On shared Wi-Fi or compromised networks, cleartext HTTP exposes headers—including Cookie. A session identifier sent without TLS is effectively handed to anyone who can observe the traffic. The Secure attribute tells browsers never to attach that cookie to insecure requests.

Secure is baseline hygiene for any authentication cookie on an HTTPS site. Combined with HSTS, it sharply reduces passive cookie theft on the wire.

How the Secure attribute works

1

Server sets Secure on Set-Cookie

The response over HTTPS marks the cookie with the Secure attribute.

2

Browser stores the cookie

The cookie remains eligible only for secure request contexts.

3

HTTPS request matches scope

On HTTPS, the cookie may be included according to Domain, Path, and SameSite rules.

4

HTTP request omits it

Cleartext requests to the same host do not receive the Secure cookie.

What Secure protects—and what it does not

Passive network sniffing

Stops the browser from volunteering the cookie on HTTP where eavesdroppers watch.

Some downgrade tricks

Reduces usefulness of forcing a victim onto HTTP just to capture that cookie.

Not XSS

Script in the page can still abuse cookie-authenticated requests if XSS exists.

Not CSRF by itself

Cross-site HTTPS requests may still include the cookie depending on SameSite.

Pairing Secure with other controls

ControlRole alongside Secure
HTTPS everywhereProvides the secure channel Secure cookies require
HSTSKeeps browsers from attempting HTTP after first trust
HttpOnlyBlocks document.cookie theft of the value
SameSiteLimits cross-site sending behavior
__Secure- / __Host- prefixesBrowser-enforces that Secure (and more) must be present

Deployment checklist

  • Mark all authentication and session cookies Secure in production.
  • Serve Set-Cookie only over HTTPS for those cookies.
  • Enable HSTS once HTTPS is reliable across required hosts.
  • Require Secure automatically when using SameSite=None.
  • Prefer __Secure- or __Host- names for high-value cookies.
  • Eliminate mixed HTTP navigation paths that drop Secure cookies and confuse users.
  • Check proxies do not strip the Secure attribute from Set-Cookie.
  • Include missing Secure flags in cookie security regression tests.

Operational pitfalls

Local development on http://localhost has special cases in some browsers, which can hide misconfigurations that appear only in staging. Another pitfall is setting Secure while still linking users to http:// bookmarks without redirects—sessions look “randomly logged out.” Fix transport redirects and HSTS rather than removing Secure.

The practical takeaway

A Secure cookie is only sent on secure (HTTPS) requests. That simple rule blocks cleartext cookie disclosure on the network.

Make Secure the default for session cookies, reinforce it with HSTS and prefixes, and combine it with HttpOnly and SameSite for a complete cookie hardening baseline.

Related security terms

Frequently asked questions

What does the Secure cookie attribute do?

It tells the browser to include the cookie only on secure requests—primarily HTTPS—so the cookie is not sent over plain HTTP.

Does Secure encrypt the cookie at rest?

No. Secure controls transmission. The browser still stores the cookie value locally without that attribute encrypting it.

Can I set a Secure cookie from an HTTP page?

Modern browsers reject attempts to set Secure cookies from insecure contexts. Serve Set-Cookie over HTTPS.

Is Secure required for SameSite=None?

Yes. Browsers require Secure when SameSite is None.

Does Secure replace HSTS?

No. Secure protects that cookie on HTTPS requests. HSTS helps keep users on HTTPS so they are less likely to make cleartext requests in the first place.

Should all cookies be Secure on an HTTPS site?

Almost always yes for production HTTPS sites. Non-Secure cookies on mixed or legacy HTTP endpoints create downgrade and sniffing risk.

What if my site still has HTTP for some assets?

Fix HTTPS completeness. Secure cookies will not be sent on HTTP requests, which can break sessions if users land on cleartext URLs.

References

Explore authoritative guidance and frameworks related to secure cookie.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary