Cookie uses SameSite=None without Secure, so it is rejected

HighConfirmedQuick winweb.cookies.samesite-none-insecure

What this check looks for

This combination is invalid and browsers throw the cookie away. Whatever it was for is not working.

Why it matters

This is not a weak cookie — it is a cookie that does not exist. Anything depending on it is silently broken, and the symptom is usually 'users get logged out at random' rather than an error anyone sees.

When the check passes, your report says: “SameSite=None is paired with Secure, so browsers keep the cookie”.

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 Secure, or change SameSite to Lax.

As it stands the cookie is discarded by the browser, so it does nothing at all.

If the cookie really is needed cross-site, add Secure and serve it over HTTPS.
If it is not, use SameSite=Lax — which is safer and does not require the pairing.

How to confirm it worked

curl -sSI https://‹host›/ | grep -i 'samesite=none'

The configuration to publish

Set-Cookie: {{cookie}}=...; Secure; HttpOnly; SameSite=None; 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› has SameSite=None without Secure. ‹detail›

RFC 6265bis §5.4 and every browser since Chrome 80 reject the cookie outright. It is almost always a leftover from adding SameSite=None to make a third-party context work without adding Secure at the same time.