In one paragraph
A cookie without a SameSite attribute leaves its cross-site sending behaviour to browser defaults rather than an explicit server decision. Set SameSite=Lax for a typical session, Strict where cross-site navigation must not carry it, or None with Secure when cross-site use is required. Check each cookie's purpose and test authentication and payment journeys before changing production settings.
Why it matters
SameSite controls whether a browser includes a cookie on requests initiated from another site. This matters for session cookies because an unwanted authenticated request can change account data even when the initiating site cannot read the response. SameSite provides a layer of protection against cross-site request forgery, or CSRF.
Lax generally allows same-site requests and cross-site top-level navigations using safe methods, such as following a normal link. It does not generally include the cookie on a cross-site POST or a background fetch. Strict withholds it on cross-site requests, including an arrival from an external link. None permits cross-site sending, subject to other browser restrictions, and requires Secure.
Some browsers apply Lax when the attribute is absent. That default can be more permissive than an explicit Lax setting: a recently created cookie may accompany a cross-site POST during a short grace period. Do not describe an undeclared cookie as a consistently enforced Lax cookie.
How WebAuditOS evaluates this finding
The supplied specification checks Set-Cookie response headers. A missing SameSite attribute fails at medium severity; SameSite=None without Secure fails at high severity. Declared attributes otherwise satisfy the presence check, and responses without cookies are not graded. A pass is not confirmation that the chosen value is appropriate for the cookie's purpose.
How to fix it
- Find the exact cookie named in the finding. In browser DevTools, inspect the response that creates it and identify whether the application, CDN, load balancer, or an external integration owns it.
- Select a value by purpose. Start the design of an ordinary session with Lax, not a blanket None rule. Use Strict only when its external-navigation behaviour is acceptable. Reserve None for flows that genuinely require cross-site cookies.
- Set the attribute where the cookie is issued. A common session configuration is:
Set-Cookie: session=REPLACE_WITH_TOKEN; Path=/; Secure; HttpOnly; SameSite=Lax
This is an example of attributes, not a token-generation implementation. Secure controls HTTPS transmission; HttpOnly prevents JavaScript cookie access; SameSite controls cross-site sending. They solve different problems.
- Review exceptions in staging. Test external links, email sign-in links, identity-provider returns, embedded widgets, and payment completion. A cross-site POST callback may not receive an explicit Lax session cookie. Follow the integration's documented design rather than weakening every cookie to fix one endpoint.
- Reissue affected cookies with the intended settings. Confirm the updated cookie in the browser storage panel and inspect fresh Set-Cookie headers. Existing stored cookies do not change simply because a configuration file was edited.
- Rescan relevant URLs and test the journeys again. Include routes that actually issue cookies: a public landing page may not expose the same response headers as login or checkout.
Retain CSRF protections on state-changing operations. Same-site is not the same boundary as same-origin, and SameSite is not a replacement for authorisation or a comprehensive defence against script injection.
What the fix can break
Strict can make a signed-in visitor appear logged out when arriving from an email or another website because the initial cross-site request lacks the cookie. This is not necessarily deletion of the session.
Changing to Lax can disrupt POST-based federation or payment return flows. None without Secure can cause browsers to reject the cookie. Even correctly configured None; Secure does not override third-party-cookie blocking, privacy controls, or an incompatible embedded authentication design.
Avoid changing unrelated preference and integration cookies through a global proxy rewrite without first understanding who consumes them.
Questions
Should every cookie use SameSite=Strict?
No. Strict has legitimate uses, but it can interfere with expected navigation and authentication. Choose by the cookie's purpose and test the full user journey.
Why declare SameSite if the browser already defaults to Lax?
An explicit value states your intended behaviour and avoids relying on a potentially different or more permissive default. It also makes the setting auditable in the response.
Does SameSite=None guarantee that an embedded login will work?
No. None with Secure allows the cookie's SameSite condition to permit cross-site sending. Other browser restrictions can still prevent storage or transmission.
What other cookie settings should I review?
See /checks/security/cookie-without-secure-flag and /checks/security/cookie-without-httponly-flag. Review those controls alongside SameSite rather than assuming any one flag makes a session secure.