SameSite Frequently Asked Questions (FAQ)
Chrome is changing the default behavior for how cookies will be sent in first and third party contexts.
- Cookies that do not specify a
SameSiteattribute will be treated as if they specified
SameSite=Lax, i.e. they will be restricted to first-party or same-site contexts by default.
- Cookies that are intended for third-party or cross-site contexts
Note: this also means cross-site or third-party cookies are restricted to secure / HTTPS connections only.
This behavior will become the default during the Chrome 80 rollout.
In the location bar, enter
chrome://flags to access the flag configuration.
Set the following flags to enabled:
Chrome is displaying warnings in the Console in DevTools which highlight each
cross-site request where cookies would be affected by the new
defaults. The cookies and their respective
SameSite and Secure attributes are
also visible in DevTools within the Application tab under Storage → Cookies.
This same information is also available in the Network Tab for each request.
- For cookies that are only required in a first-party context, you
should ideally set an appropriate
SameSitevalue of either
Secureif your site is only accessed via HTTPS.
- For cookies that are required in a third-party context, you must set
Refer to following guidance:
No. Chrome on iOS (as with all other browsers) uses the underlying WebKit engine and does not currently enforce the new defaults.
The test site: https://samesite-sandbox.glitch.me/ will show the presence of a variety of cookies in a same-site and cross-site context along with whether that’s correct for the new defaults. If all rows show with a green check mark: ✔️ then the browser is enforcing the new defaults.
Ideally, sites should be upgrading to HTTPS and cross-site cookies will not be
sent over a plain HTTP connection. However, on an HTTP page with HTTPS resources
then those secure requests will include cookies that have been marked with
Sites that rely on services making use of third-party cookies should ensure they
are including those resources (scripts, iframes, pixels, etc.) via an
appropriate HTTPS URL. You can see this in action on this test site:
A reasonable rule is if the connection is an upgrade, i.e. HTTP page with HTTPS resources then they can have cookies. However, a downgrade, i.e. an HTTPS page with HTTP resources will not get cookies on cross-site HTTP resources and users will most probably see mixed content warnings in the browser UI.
In general, make all requests over HTTPS where possible.
This is a specific exception made to account for existing cookie usage on some
Single Sign-On implementations where a CSRF token is expected on a cross-site
POST request. This is purely a temporary solution and will be removed in the
future. It does not add any new behavior, but instead is just not applying the
SameSite=Lax default in certain scenarios.
Specifically, a cookie that is at most 2 minutes old will be sent on a top-level
cross-site POST request. However, if you rely on this behavior, you should
update these cookies with the
SameSite=None; Secure attributes to ensure they
continue to function in the future.
Chrome extensions use the
chrome-extension:// URL scheme, which appears as
cross-site to anything
http://. The fix, which is to
extension-initiated requests as same-site*****, is available in Chrome 79 and
later. Some use cases involving requests made from web frames on extension pages
may also behave differently in Chrome 80. If you test on newer (80+) versions of
Chrome and find that your extension is still broken, please file a bug on
crbug.com using this template.
* If the extension has host permissions access to the page.
[UPDATE Jan 8, 2021: The modern SameSite behavior (SameSite=Lax by default, SameSite=None requires Secure, and Schemeful Same-Site) will be enabled by default for Android WebView on apps targeting Android S and newer. Existing apps will not be affected until they choose to update to target Android S. Android S has not yet been released. Existing apps can be tested with the new modern SameSite behavior by toggling the flag webview-enable-modern-cookie-same-site in the developer UI.]
The new though app developers are advised to declare the appropriate
SameSite behavior will not be enforced on Android Webview until
cookie settings for Android WebViews based on versions of Chrome that are
compatible with the None value, both for cookies accessed via HTTP(S) headers
and via Android WebView's CookieManager
does not apply to Chrome browser on Android, which will begin to enforce the new
SameSite rules at the same time as the desktop versions of Chrome.