Finding: Cookie Missing Secure Flag
A cookie set by this site is missing the Secure attribute, so the browser is permitted to send it over an unencrypted HTTP connection too, not just HTTPS.
Last updated August 11, 2026.
What it means
The Secure attribute on a Set-Cookie header tells the browser to only ever send that cookie back over an HTTPS connection. Without it, the browser will happily attach the same cookie to a plain HTTP request if one is ever made — for example if a visitor follows an old http:// link, types the domain without a scheme, or lands on the site through a network that strips HTTPS. This finding is scoped to that flag alone: it says nothing about whether the cookie is also missing HttpOnly or SameSite, which are reported as their own separate findings.
Why it matters
If a visitor ever touches the unencrypted version of the site — even briefly, even by accident — a cookie without Secure is sent in a form readable by anyone positioned between them and the server on that connection. For a session or authentication cookie, that means the value that keeps someone signed in becomes readable in transit, which is the same underlying risk a missing HTTPS redirect creates, just scoped to one specific cookie rather than the whole page.
What Nivaronix checks
Nivaronix makes a live request to the domain and inspects each Set-Cookie header in the response, parsing its attributes. This finding fires once per cookie found without a Secure attribute. This is a configuration check against the live response — not a vulnerability scan.
Example evidence (illustrative — not live scan data)
Missing Secure:
Set-Cookie: session=abc123; Path=/; HttpOnly
Fixed:
Set-Cookie: session=abc123; Path=/; HttpOnly; Secure
How to fix it
Cookies are usually set by application code rather than web server config, so the fix is almost always a one-line change to the cookie options in your framework, not a header rewrite rule.
Express (Node.js)
res.cookie("session", token, {
httpOnly: true,
secure: true,
sameSite: "lax",
});Django
# settings.py SESSION_COOKIE_SECURE = True CSRF_COOKIE_SECURE = True
Rails
# config/environments/production.rb Rails.application.config.session_store :cookie_store, secure: true
Raw header
Set-Cookie: name=value; Secure; HttpOnly; SameSite=Lax
How to verify the fix
Open your browser's DevTools → Application (Chrome) or Storage (Firefox) → Cookies, select the cookie, and confirm the Secure column is checked. Or re-run the website security scanner and confirm this finding no longer appears.
Related
FAQ
If my whole site redirects to HTTPS, do I still need the Secure flag?
Yes — a site-wide HTTPS redirect protects new connections, but it doesn't prevent a cookie from being attached to an occasional stray HTTP request: an old bookmark, a hardcoded http:// link somewhere, or a network that strips HTTPS before the redirect happens. The Secure flag is what stops the browser from ever sending that cookie over such a request, independent of what the redirect does.
Does Secure alone make a cookie fully protected?
No — Secure only controls transport (HTTPS-only). HttpOnly (blocks JavaScript access, defending against XSS-driven theft) and SameSite (limits cross-site sending, defending against CSRF) cover different attack surfaces and are reported as their own separate findings. A session cookie should generally carry all three.
Will adding Secure break my site in local development?
It can, if your local dev server runs over plain HTTP — a Secure cookie set in that environment won't be sent back by the browser. Most frameworks let you set secure: true conditionally based on environment (e.g. NODE_ENV === 'production'), so the flag applies in production without breaking local HTTP development.
Does this finding mean my cookie has already been stolen?
No — it's a configuration gap, not evidence of an actual theft. It means the condition that would let a network attacker read the cookie exists if a visitor's connection ever touches plain HTTP; it doesn't mean that has happened to any specific visitor.