dotvitals

Cookie has no SameSite attribute

MediumConfirmedQuick winweb.cookies.no-samesite

What this check looks for

You have not said whether this cookie should be sent when another website triggers a request to yours. Browsers each pick their own default, so the behaviour differs between them.

Why it matters

SameSite is what stops another site making an authenticated request as your logged-in visitor. Leaving it unset means relying on a default that Chrome and Firefox do not agree on, so the same site behaves differently per browser.

When the check passes, your report says: “The cookie states its SameSite behaviour explicitly”.

What it costs your score

When this check fails it removes 8 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
warn
Deduction
8 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

Set SameSite explicitly on every cookie.

The default is not the same in every browser, so the behaviour is not the one you tested.

  1. Use SameSite=Lax for session cookies on a normal site.

  2. Use SameSite=Strict for cookies that authorise an action.

  3. Use SameSite=None; Secure only when a third-party context genuinely needs the cookie.

How to confirm it worked

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

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› has no SameSite attribute. ‹detail›

Chrome applies Lax by default with a two-minute exception for top-level POST requests; Firefox and Safari have not matched it. Set it explicitly: Lax suits a session cookie on a normal site, Strict suits anything that authorises an action, and None — which requires Secure — is only for a cookie that genuinely has to travel from a third-party context.

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