Is SameSite=None safe?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• SameSite=None disables SameSite protection and sends the cookie on every request.
• Browsers require the Secure flag for SameSite=None, so the cookie is only sent over HTTPS.
• Use SameSite=None only when cross - site functionality is required and combine it with CSRF mitigations.
• For first - party sites, prefer SameSite=Lax (default) or SameSite=Strict.

What does SameSite=None actually do?

SameSite=None tells the browser to send the cookie with both same - site and cross - site requests. It does not give any CSRF protection because the cookie is included in every request, including POSTs triggered from another site.

The attribute is meant for situations where a cookie must be available to third - party services, such as embedded payment widgets or federated login flows. If your application does not need that, you should avoid SameSite=None.

Why does the browser require Secure with SameSite=None?

When SameSite=None is used, browsers reject the cookie unless it also has the Secure flag. This requirement forces the cookie to travel only over HTTPS, which protects it from passive network eavesdropping.

The Secure flag is not required for SameSite=Lax or SameSite=Strict, so the enforcement is specific to SameSite=None. The rule also helps limit tracking by preventing long - lived cross - site cookies from being sent over plain HTTP.

Security implications of using SameSite=None

• CSRF exposure - Because the cookie is sent on any cross - site request, an attacker can trigger state - changing actions if the site relies only on the cookie for authentication. Add anti - CSRF tokens, Origin/Referer checks, or double - submit cookie patterns to mitigate this.
• Privacy and tracking - Third - party services can set persistent SameSite=None; Secure cookies that survive across many sites, enabling cross - site tracking.
• Network - level risk - If an older browser ignores the Secure requirement, the cookie could be transmitted over HTTP and be sniffed. Modern browsers enforce the rule, but you should still serve all pages over HTTPS.
• Browser compatibility - Some legacy browsers treat SameSite=None as invalid and fall back to Strict or ignore the Secure flag, leading to inconsistent behavior.

When can SameSite=None be considered safe?

• Serve the entire site over HTTPS.
• Implement additional CSRF defenses such as anti - CSRF tokens or Origin checks. | First - party only site that does not need cross - site access | - Do not use SameSite=None.
• Use the default SameSite=Lax or the stricter SameSite=Strict.

How to implement SameSite=None correctly

1. Add the Secure attribute to the Set - Cookie header.

Set-Cookie: sessionId=abc123; SameSite=None; Secure; Path=/; HttpOnly; SameSite=None

1. Ensure every endpoint that serves the cookie is reachable only via HTTPS.
2. Deploy a CSRF mitigation strategy:

• Include a random token in HTML forms and verify it on the server.
• Validate the Origin or Referer header for state - changing requests.
• Consider the double - submit cookie pattern as an extra layer.

1. Test across browsers, especially older versions of Safari and Chrome, to verify that the cookie is accepted and sent as expected.

Bottom line

SameSite=None is not a security feature; it is a compatibility flag that deliberately disables SameSite restrictions. The only safety it adds is the mandatory Secure flag, which forces HTTPS transmission. To use it safely, you must serve your site over HTTPS and add independent CSRF protections. For most applications that do not need cross - site cookie access, avoid SameSite=None and stick with SameSite=Lax (default) or SameSite=Strict.

References

• MDN - Set - Cookie SameSite attribute. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
• OWASP - SameSite. https://owasp.org/www-community/SameSite
• Web.dev - SameSite cookies explained. https://web.dev/articles/samesite-cookies-explained
• Chromium FAQ - SameSite. https://www.chromium.org/updates/same-site/faq/
• IETF draft - west - cookie - incrementalism - 01, §3.2. https://datatracker.ietf.org/doc/html/draft-west-cookie-incrementalism-01#section-3.2
• PortsWigger - Bypassing SameSite restrictions. https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions
• Web.dev - SameSite cookie recipes. https://web.dev/articles/samesite-cookie-recipes