dotvitals

Cookie sets a Domain the browser will not accept, so it is discarded

HighConfirmedQuick winweb.cookies.domain-not-accepted

What this check looks for

The cookie names a domain that this host is not part of. A browser does not narrow the scope in that case — it throws the whole cookie away, so the cookie is never stored at all.

Why it matters

This is not a cookie with the wrong scope; it is a cookie that does not exist. Whatever depended on it fails silently, and because the header is present in the response it looks set to anyone reading the response by eye.

When the check passes, your report says: “The cookie's Domain is one the browser accepts”.

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

Correct the Domain value, or remove the attribute.

As written, the browser discards the cookie and nothing that depends on it works.

  1. Remove Domain entirely — the cookie then belongs to the host that set it, which is what most cookies want.

  2. If it has to be shared, set Domain to a domain this host sits under, and never to a public suffix such as co.uk.

  3. Check the value is not left over from another environment; a staging domain on production fails exactly this way.

How to confirm it worked

  • curl -sSI https://‹host›/ | grep -i '^set-cookie:' — then confirm the browser stored it in DevTools → Application → Cookies

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› sets Domain=‹value›, and ‹host› does not domain-match it. ‹detail›

RFC 6265bis §5.7 requires the user agent to ignore the cookie entirely when the request host does not domain-match the domain-attribute — there is no fallback to a host-only cookie. The usual causes are a typo, a Domain copied from another environment, and a cookie set for a parent domain that is a public suffix.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the web cookies checkerBuild the fix

Other web cookies checks