updates > SameSite Updates >
Q: What are the new SameSite changes?
Chrome is changing the default behavior for how cookies will be sent in firstand third party contexts.
- Cookies that do not specify a
SameSiteattribute will be treatedas if they specifiedSameSite=Lax, i.e. they will be restricted tofirst-party or same-site contexts by default. - Cookies that are intended for third-party or cross-site contextsmust specify
SameSite=NoneandSecure.
Note: this also means cross-site or third-party cookies are restricted to secure/ HTTPS connections only.
Q: When do the new SameSite changes roll live?
This behavior will become the default during the Chrome 80 rollout.
Q: How can I test the new SameSite defaults?
In the location bar, enter chrome://flags to access the flag configuration.Set the following flags to enabled:
chrome://flags/#same-site-by-default-cookieschrome://flags/#cookies-without-same-site-must-be-secure
Q: How can I tell if my cookies are affected?
Chrome is displaying warnings in the Console in DevTools which highlight eachcross-site request where cookies would be affected by the new SameSitedefaults. The cookies and their respective SameSite and Secure attributes arealso visible in DevTools within the Application tab under Storage → Cookies.This same information is also available in the Network Tab for each request.
Q: What do I need to do to my cookies?
- For cookies that are only required in a first-party context, youshould ideally set an appropriate
SameSitevalue of eitherLaxorStrictand setSecureif your site is only accessed viaHTTPS. - For cookies that are required in a third-party context, you must setthe
SameSite=NoneandSecureattributes.
Q: How do I handle older or incompatible browsers?
Refer to following guidance:
- https://web.dev/samesite-cookie-recipes/#handling-incompatible-clients
- https://www.chromium.org/updates/same-site/incompatible-clients
Q: Are the new defaults applied to Chrome on iOS?
No. Chrome on iOS (as with all other browsers) uses the underlying WebKit engineand does not currently enforce the new defaults.
Q: How can I tell if my browser is applying the new SameSite defaults?
The test site: https://samesite-sandbox.glitch.me/ will show the presence of avariety of cookies in a same-site and cross-site context along with whetherthat’s correct for the new defaults. If all rows show with a green check mark:✔️ then the browser is enforcing the new defaults.
Q: What if I have an HTTP page and need third-party cookies?
Ideally, sites should be upgrading to HTTPS and cross-site cookies will not besent over a plain HTTP connection. However, on an HTTP page with HTTPS resourcesthen those secure requests will include cookies that have been marked withSameSite=None; Secure.Sites that rely on services making use of third-party cookies should ensure theyare including those resources (scripts, iframes, pixels, etc.) via anappropriate HTTPS URL. You can see this in action on this test site:http://crosssite-sandbox.glitch.me/
A reasonable rule is if the connection is an upgrade, i.e. HTTP page with HTTPSresources then they can have cookies. However, a downgrade, i.e. an HTTPS pagewith HTTP resources will not get cookies on cross-site HTTP resources and userswill most probably see mixed content warnings in the browser UI.
In general, make all requests over HTTPS where possible.
Q: What is the Lax + POST mitigation?
This is a specific exception made to account for existing cookie usage on someSingle Sign-On implementations where a CSRF token is expected on a cross-sitePOST request. This is purely a temporary solution and will be removed in thefuture. It does not add any new behavior, but instead is just not applying thenew SameSite=Lax default in certain scenarios.
Specifically, a cookie that is at most 2 minutes old will be sent on a top-levelcross-site POST request. However, if you rely on this behavior, you shouldupdate these cookies with the SameSite=None; Secure attributes to ensure theycontinue to function in the future.
Q: Why doesn’t my extension work anymore under the new SameSite rules?
Chrome extensions use the chrome-extension:// URL scheme, which appears ascross-site to anything https:// or http://. The fix, which is totreatextension-initiated requests as same-site*****, is available in Chrome 79 andlater. Some use cases involving requests made from web frames on extension pagesmay also behave differently in Chrome 80. If you test on newer (80+) versions ofChrome and find that your extension is still broken, please file a bug oncrbug.com using this template.
*Ifthe extension has host permissions access to the page.
Q: Are cookies in WebViews affected by the new default behavior?
[UPDATE Jan 8, 2021: The modern SameSite behavior (SameSite=Lax bydefault, SameSite=None requiresSecure, and SchemefulSame-Site) will be enabled by default forAndroid WebView on apps targeting Android S and newer. Existing apps will not beaffected until they choose to update to target Android S. Android S has not yetbeen released. Existing apps can be tested with the new modern SameSite behaviorby toggling the flag webview-enable-modern-cookie-same-site in the developerUI.]
The new though app developers are advised to declare the appropriate SameSite behavior will not be enforced on Android Webview untillater,SameSitecookie settings for Android WebViews based on versions of Chrome that arecompatible with the None value, both for cookies accessed via HTTP(S) headersand via Android WebView's CookieManagerAPI. Thisdoes not apply to Chrome browser on Android, which will begin to enforce the newSameSite rules at the same time as the desktop versions of Chrome.
