ASVS 5.0 V3.3.2 requires that each cookie's SameSite attribute is set according to what the cookie is for, to limit user interface redress attacks and browser based request forgery (CSRF). It is a Level 2 requirement.
Why it matters
By default a browser attaches cookies to requests that another site triggers, such as a hidden form posting to your bank. SameSite tells the browser when to withhold them. The right value depends on the cookie, so a blanket choice is often wrong in one direction or the other.
How to implement it
Strict: the cookie is sent only for requests from the same site. Use it for sensitive cookies where the user does not arrive from outside links, such as an admin session.Lax: also sent on top level navigations that use safe methods, like clicking a link. This is the usual choice for session cookies on ordinary sites.None: sent in all contexts and requiresSecure. Use it only when the cookie must work in a cross site embed, for example a widget you provide.
res.cookie("__Host-session", id, { secure: true, httpOnly: true, sameSite: "lax", path: "/" });
res.cookie("__Host-admin", id2, { secure: true, httpOnly: true, sameSite: "strict", path: "/" });
Write the choice for each cookie in documentation. SameSite is a defense in depth layer, so keep CSRF tokens on state changing requests as well.
How to test it
List every cookie with its SameSite value, then ask what breaks if it is set to the strictest possible value. From a page on another origin, submit a form to a state changing endpoint and confirm the session cookie is not sent.
Which value for which cookie
A practical mapping many teams use:
- Session cookie for a normal site:
Lax, so users following a link from email or search stay logged in. - Session cookie for an admin console or banking area:
Strict, accepting that an incoming link may ask them to sign in again or reload. - CSRF token cookie:
StrictorLax, depending on whether it must be present on navigations. - Embedded widget or payment frame served from your domain on other sites:
NonewithSecure, plus its own CSRF defenses. - Preference cookies:
Laxis fine.
Remember that "same site" means the same registrable domain, so a sibling subdomain counts as same site. If untrusted code runs on a subdomain, SameSite will not stop it. That is another reason to separate user content onto its own domain.
Common mistakes
- Using
Noneto fix a login redirect problem whenLaxwould do. - Relying on browser defaults instead of setting the value.
- Treating SameSite as a replacement for CSRF tokens.
Quick check
When is SameSite=None acceptable?
When the cookie truly must be sent in cross site contexts, and it also carries Secure.
