ON THIS PAGE
- How SameSite Affects Third-Party Cookies
- Lax vs. Strict SameSite Cookies Attributes
- Developers Should Update As Soon as Possible… Here’s Why
- Check if Your Website is Compatible with Chrome 80
- Why You Should Be Using CookieScript on Your Website
SameSite cookie attribute is used by browsers to identify how first- and Third-Party Cookies should be handled. Browsers can either allow or block such cookies depending on attribute and scenario. In this article, we will explain all the aspects of the SameSite attribute in detail.
How SameSite Affects Third-Party Cookies
Starting in February 2020, Google is rolling out Chrome 80 in waves. One notable aspect of this release is that the SameSite cookies attribute will be turned on by default. This feature is designed to protect the privacy rights of web users by preventing the transfer of cookies through cross-origin requests. It has been available since Chrome 76 but has been tucked away in the preferences. To some degree, this new feature also adds some much-needed security in reducing the risk of cross-site request forgeries (CSRF).
You can check out the latest information on the Chrome 80 rollout by visiting the SameSite schedule page. If you’re curious whether your browser has adopted the new cookie standard you can visit the samesite-sandbox.glitch.me website. If all rows are highlighted in green then your browser has been updated to the latest cookie standard.
Lax vs. Strict SameSite Cookies Attributes
On your website, you have two options when establishing a SameSite cookie value: Lax and Strict.
“Strict” value. As the name implies, the “Strict” value is a more aggressive form of cross-site request forgery prevention. With the SameSite=Strict value, the web browser prevents cookie data from being transferred during cross-domain requests in all instances. A majority of websites that choose to set their SameSite value as “Strict” will be those in financial services, web banks, cryptocurrency, and others at high risk of cross-site request forgery attacks (CSRF).
At first, the “Strict” setting will take away some of the usability features that users have grown accustomed. For example, if you click on an external link that leads to a website that typically populates customization options from cookies, this data will likely not load correctly. You may have to type in the address in the toolbar in order to restore the customized features of the website. These hiccups should disappear as more users adopt the new standards and rebuild their SameSite-compatible cookies.
“Lax” value. The “Lax” value in SameSite is a more relaxed form of cross-site request protection. With this setting, your web browser will allow most cross-domain cookie-sharing so long as these originate from a top-level GET request.
Developers Should Update As Soon as Possible… Here’s Why
Many of the headaches of the transition can be avoided so long as developers and providers update their cookies to the latest standard in advance of the rollout. Developers that update early will avoid the gripes from users who have already updated to the latest standard.
Preserve Top-Level Cross-Site Cookies
To preserve the browsing experience of legacy users, Google has implemented a temporary mitigation scheme known as Lax + POST. This feature gives users a two-minute grace period where cookies with unspecified SameSite settings may be passed between a website and a third-party service provider. This is done to avoid interruptions of normal website operation. It is important to note that Lax + POST mitigation does not apply to cross-site GET requests, which will automatically be tagged with the “Lax” label.
Third-party sign-ons. If you offer third-party sign-ons from your website, it is strongly suggested that you put your sign-on flow through its paces to ensure it is compatible with the latest SameSite Settings.
SameSite may affect enterprise users. As many enterprise users conduct work via internal applications and third-party sign-on tools, administrations may need to switch users' Chrome browsers so they are reverted to legacy settings.
Give Your Website a “Stress Test”
If you're unsure how your website or service functions under the latest SameSite model, you can perform a "stress test" by switching on the "SameSite by default cookies" settings, a feature available in Chrome 76 and above. Also, be sure to enable the "Cookies without SameSite must be secure." You can enable this experimental flag by visiting chrome://flags in your Chrome browser. Flags should also be enabled in Chrome 80 to make sure the default settings are carried over into the latest version.
Troubleshoot Unexpected Behaviors
Let's say you've already upgraded to Chrome 80, but you're wondering if some new "quirks" of the latest stable release are caused by the latest settings. To test this, you can reverse the previously mentioned troubleshooting and testing procedure by switching off the "SameSite by default cookies" and disabling flags for "Cookies without SameSite must be secure." If your browser no longer experiences the same issues as before then it is likely that the new cookies standard was to blame for the issues.
Check if Your Website is Compatible with Chrome 80
Within the Developer Tools console, you can check the compatibility of your website to ensure settings are configured for the new standard. Since the rollout of Chrome 80 is gradual, you may see a warning even though everything is working as it should.
To meet the new standards, many services are using redundant cookies, that this, they are sending duplicate cookies; one that conforms to legacy settings and the other that is compatible with the latest standards. Many Google services are currently using the ”dual-cookie method,“ so you may see the Developer Tools console flag a cookie with a legacy setting, but the cookie with the new setting passes through without issue. This minor annoyance is temporary and will become less of an issue as more people transition to the new standard.
Why You Should Be Using CookieScript on Your Website
Keeping up with the latest cookie regulations and making sure your website is in compliance is a job in itself. CookieScript keeps you compliant with GDPR, CCPA, ePR, and other regulations that are surely on the horizon. And, it’s super-easy to use.
How it Works
CookieScript automatically does the following:
- Scans your website for cookies
- Categorizes and adds descriptions to your cookies
- Maintains a full history of user consents (as required by GDPR)
- Allows users to withdraw consent at any time
- Block cookies until visitor consents (GDPR and CCPA)
Block Third-Party Cookies by default. CookieScript also gives you the option to prevent Third-Party Cookies from running on your website and it also makes the web a friendlier, more transparent experience for businesses and users.