Home / Knowledge hub / Secure cookie flag
Knowledge hub
Secure cookie flag
A setting that makes the browser send a cookie only over HTTPS.
What it means
The Secure flag is an attribute on a cookie. When it is set, the browser sends that cookie only over an encrypted HTTPS connection and never over plain HTTP. Without it, the browser sends the cookie on any request to the site, encrypted or not.
The danger is the unencrypted request. A visitor types your domain without https, or follows an old http link, or a page loads one http image. The browser then sends the cookie in the clear, where anyone on that network can read it.
Why it matters
A session cookie read off the network is a ready-made account. Public Wi-Fi, a shared office network and a compromised router are all places where it can happen, and the user will notice nothing. The attacker uses the cookie and the app sees a normal signed-in visitor.
It is one of the cheapest fixes in web security, yet it is still missing on session cookies in real audits. Auditors, customers and pentest reports flag it quickly, and it often suggests the rest of the cookie settings have not been reviewed either.
How it shows up
Set it on every cookie that carries identity, which includes the session, the refresh cookie and any "remember me" value. Most frameworks have one setting that turns it on. Use it with HSTS so browsers never make the first plain request, and with the __Secure- and __Host- prefixes for stronger guarantees.
The mistakes repeat: it works in production but is switched off in a staging copy that holds real data; a load balancer ends TLS and the app wrongly thinks the request is plain HTTP and drops the flag; and one cookie set by a second system lacks it. Check the Set-Cookie response on login, and on each domain that sets one.
Questions people ask
Secure cookie flag, answered
Does the Secure flag encrypt a cookie?
No. It only controls when the browser sends it. The value is still readable by the user and by scripts, unless HttpOnly is set. Encryption of traffic comes from HTTPS.
The flag makes sure the cookie never travels outside that encryption.
Do we still need it if the whole site is HTTPS?
Yes. A visitor can still reach an http address, and an attacker can cause a request to it. Without Secure, the cookie goes with that first request.
HSTS helps close the gap, and Secure is the direct fix.
Can a site set a Secure cookie from an HTTP page?
Current browsers refuse a Secure cookie set over plain HTTP, so it cannot be created that way. But an insecure page could still overwrite a non-Secure cookie with the same name.
Prefixes make this harder.
What is the difference between Secure and HttpOnly?
Secure limits the connection a cookie travels on. HttpOnly limits who can read it in the browser. One protects against network eavesdroppers, the other against hostile page script.
A session cookie normally needs both, plus SameSite.
How do we test the flag?
Check the Set-Cookie header and the cookie list in the developer tools. Then request the plain HTTP version of the site and watch whether the cookie is sent.
A proxy makes both checks easy.
Related
Terms that sit next to this one
HSTS
A header telling browsers to use HTTPS only for your site, every time.
HttpOnly cookie
A cookie that page scripts cannot read, so XSS cannot simply steal it.
SameSite cookie
A cookie setting that limits when a browser sends it on requests from other sites.
Cookie prefix
A name prefix such as __Host- that makes browsers enforce stricter cookie rules.
HTTPS
The encrypted web protocol, and the minimum for anything with a login.
Does the cookie ever travel unencrypted?
We check the cookies your app sets and whether any can be sent over plain HTTP. Anything we flag comes with the response that showed it. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.