Cookie is sent over unencrypted connections

HighConfirmedQuick winweb.cookies.no-secure

What this check looks for

This cookie has no Secure flag, so the browser also sends it over plain HTTP. Anyone on the same network can read it from that request.

Why it matters

If the cookie is a session token, reading it is enough to become the logged-in user — no password needed. The browser only has to be tricked into making one plaintext request to the domain, which a single image tag on any page can do.

When the check passes, your report says: “The cookie is marked Secure and never sent over plain HTTP”.

What it costs your score

When this check fails it removes 15 points from your Web security score, before the status, confidence and repeat multipliers are applied. Web security carries a weight of 8 in the overall score.

It shares the web-security.cookies family ceiling of 30 points: however many findings that family produces, together they cannot remove more than that from Web security. One underlying problem showing up in several places is still one problem.

Severity: high
Default confidence: confirmed
Status when triggered: fail
Deduction: 15 points
Family cap: web-security.cookies · 30
Category: Web security
Module: Web cookies
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Add the Secure attribute to every cookie.

Without it the cookie travels in the clear on any plaintext request to the domain.

Set Secure where the cookie is created — in the application, not in the web server.
Consider renaming the cookie with a __Secure- prefix, which makes browsers enforce the flag for you.
Rotate any session token that has been sent without Secure; treat it as exposed.

How to confirm it worked

curl -sSI https://‹host›/ | grep -i '^set-cookie:' — every cookie should carry Secure

The configuration to publish

Set-Cookie: {{cookie}}=...; Secure; HttpOnly; SameSite=Lax; Path=/

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

# Only for a cookie from an upstream you cannot change. Fix it in the application first.
proxy_cookie_flags ~ secure httponly samesite=lax;

Apache

<IfModule mod_headers.c>
	# Workaround for a cookie from an upstream you cannot change.
	Header always edit Set-Cookie ^((?!.*;\s*Secure).*)$ "$1; Secure; HttpOnly; SameSite=Lax"
</IfModule>

Caddy

header {
	+Set-Cookie "{http.response.header.Set-Cookie}; Secure; HttpOnly"
}

Express

res.cookie('session', value, {
  secure: true,
  httpOnly: true,
  sameSite: 'lax',
  path: '/',
});

Requires nginx 1.19.3 or later. This rewrites cookies passing through the proxy; it cannot help for a cookie the browser receives some other way.
Shown because the response identified Apache. It is a last resort: set the attributes where the cookie is created. Put it in the virtual host — .htaccess runs too late to edit a header the proxy module has already emitted.
Also a workaround; prefer setting the attributes in the application.

Technical detail

‹cookie› was set without the Secure attribute. ‹detail›

HSTS reduces the exposure but does not remove it: it applies per host and only after the browser has seen the header once. Secure is unconditional, costs nothing, and is set where the cookie is created rather than at the web server.