Cookie name promises protections its attributes do not provide

MediumConfirmedQuick winweb.cookies.prefix-requirements-unmet

What this check looks for

The cookie's name starts with a special prefix that browsers enforce rules for, and those rules are not met — so the browser rejects the cookie entirely.

Why it matters

Again, this is a cookie that is not set at all rather than one that is set weakly. Whatever depends on it fails silently, and because the name looks deliberately hardened it is the last place anyone looks.

When the check passes, your report says: “The cookie meets the rules its name prefix promises”.

What it costs your score

When this check fails it removes 10 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: medium
Default confidence: confirmed
Status when triggered: fail
Deduction: 10 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

Meet the prefix's requirements, or drop the prefix from the name.

Until they match, the browser discards the cookie completely.

__Secure-: add the Secure attribute.
__Host-: add Secure, set Path=/, and remove Domain entirely.
If the cookie must be shared with subdomains, __Host- is the wrong prefix — use __Secure-.

How to confirm it worked

curl -sSI https://‹host›/ | grep -i '^set-cookie:'

The configuration to publish

Set-Cookie: __Host-{{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› carries the ‹prefix› prefix. ‹detail›

RFC 6265bis §4.1.3: __Secure- requires Secure; __Host- requires Secure, Path=/ and *no* Domain attribute. The browser checks these before accepting the cookie, which is what makes the prefixes worth using — but it means a mismatch discards the cookie rather than downgrading it.