A cookie holding a session token is a password that travels with every request. Two attributes decide how exposed that token is: Secure and HttpOnly. Neither changes what the cookie does. Both change who can read it and over what connection, and leaving them off is one of the most common findings in a web security review.
Secure: HTTPS only
Add Secure and the browser sends the cookie only over an encrypted HTTPS connection. On a plain http:// request the cookie is withheld, which shuts down a specific attack: someone sitting on the network (a cafe Wi-Fi, a compromised router) watching for a session cookie sent in the clear. Without Secure, a single accidental HTTP request can leak the token to anyone listening.
One exception: browsers allow Secure cookies over http://localhost so local development still works. Everywhere else, no HTTPS means no cookie. Note what Secure does not do. It doesn't encrypt the cookie's contents, and it doesn't stop someone with access to the device from reading it off disk. It governs the transport, nothing more.
HttpOnly: invisible to JavaScript
By default any script running on your page can read every cookie through document.cookie. That's fine for a UI preference and dangerous for a session token, because a single cross-site scripting (XSS) hole lets an injected script scoop up the cookie and ship it to an attacker's server.
Set HttpOnly and the cookie disappears from document.cookie entirely. The browser still sends it on requests, so the server side keeps working, but JavaScript can't see it. XSS is still bad news, yet an HttpOnly session cookie is no longer part of the loot. Any cookie that authenticates a user should carry HttpOnly. Analytics and tracking cookies deliberately don't, because their scripts need to read and write them from JavaScript, which is exactly why those cookies are more exposed.
The flags are independent, use both where it counts
Secure and HttpOnly solve different problems. Secure stops interception on the wire; HttpOnly stops theft by injected script. A session cookie wants both, plus a SameSite value. A typical hardened session cookie reads: Set-Cookie: id=...; Secure; HttpOnly; SameSite=Lax.
What each flag protects against
| Concern | Secure | HttpOnly |
|---|---|---|
| Network eavesdropping (man in the middle) | Blocks it | No effect |
| Theft via XSS reading document.cookie | No effect | Blocks it |
| Cookie sent over plain HTTP | Prevented | Still sent |
| Readable by page JavaScript | Yes | No |
Cookie name prefixes: __Secure- and __Host-
Attributes can be stripped or spoofed in some attack scenarios, so the cookie spec adds a defense baked into the name itself. Two prefixes act as browser-enforced contracts:
__Secure-: a cookie whose name starts with this must be set with theSecureattribute from an HTTPS page, or the browser refuses it.__Host-: stricter still. The cookie must beSecure, must setPath=/, and must not include aDomainattribute. That last rule pins the cookie to the exact host that set it, so a sibling subdomain can't write a cookie your top-level site would then trust.
The prefix is part of the real cookie name. Your server has to read __Host-session, not session, because browsers send the full name and never strip the prefix. It's a small change that makes a whole category of subdomain and downgrade attacks impossible.
What these flags don't do
It's easy to over-trust them. HttpOnly stops a script from reading a cookie, but it does nothing against cross-site request forgery, where an attacker's page triggers a request and the browser dutifully attaches your cookie. The attacker never reads the cookie; it just gets used. That's a job for SameSite and anti-CSRF tokens, not HttpOnly. In the same way, Secure protects the cookie in transit but does nothing once it's sitting in the browser's cookie store, where malware or physical access can still reach it. Treat each flag as closing one specific door, and layer them rather than lean on any single one.
How this connects to consent
Flags and consent answer different questions. Secure and HttpOnly harden a cookie you're allowed to set; consent decides whether you're allowed to set it at all. A tracking cookie can be locked down perfectly and still be unlawful if you dropped it before the visitor agreed.
The two meet in the audit. Because analytics and marketing cookies are usually readable by JavaScript (no HttpOnly) and set by third-party scripts, they're the ones a scanner flags for consent. CookieBeam's scanner records each cookie's flags next to its purpose, so you can see at a glance which cookies are session-critical and hardened versus which are trackers waiting on consent. Because the tool holds tagged third-party scripts until the visitor opts in, the trackers those scripts create never get set on a reject. For what happens to already-stored cookies when someone declines, see what happens when you reject cookies.
A quick checklist
- Session and auth cookies:
SecureplusHttpOnlyplus aSameSitevalue, ideally with a__Host-name. - Serve the whole site over HTTPS so
Securenever blocks a legitimate request. - Don't put anything sensitive in a JavaScript-readable cookie; if a script needs it, assume it can leak.
- Check the flags in DevTools under Application then Cookies, where
SecureandHttpOnlyeach have a column.
Related reading: the SameSite attribute, how the Set-Cookie header works, and cookie categories.