The release of Chrome 84 brings a new behaviour for those cookies without the
SameSite attribute, and it seems like the rest of browsers will follow the same steps. Let us tell you about the new changes and how to detect them.
You may have found trouble in the last days when trying to use a web app, a custom analytics script, a non-SSL development environment or a site you access from an external login. If you are a Google Chrome user, you can bet this is because its new default behaviour towards those cookies without the
If this has happened to you, sorry not sorry 🤷♂️😅. It won’t be me who stop you from using a browser like Firefox, where this does not happen (yet). But in this case, this change set by Chrome developers may be a good thing, and I would like to tell you why.
First of all, I would like to explain briefly what both the
Secure attribute are.
As explained in MDN:
SameSite=<samesite-value>: it makes sure that a cookie is not sent on those cross-origin requests, which provides some protection against CSRF forgery attacks.
Strict: the browser will send the cookie ony for those same-site requests (in other words, requests originated from the same site where the cookie was set). Whenever this request was originated from a different URL, cookies with the attribute
SameSite=Strictwill not be sent.
Lax: the cookie will not be sent for those cross-site requests, such as in those calls to load images or frames. However, it will be sent when a user is entering this URL from an external site (for example, when following a link).
None: the browser will send the cookie in both same-site and cross-site requests.
Secure: a cookie with this attribute will only be sent to the server when the request is made using the
What it the real difference between
Whenever a site has set its cookie as
Strict, you will need to login again when clicking on a link to a web’s document with a login requirement. Yes, it does not matter if your session is already open in another tab: you are entering that web from an external link and this has made the browser block your cookies.
Lax option, cookies would in fact be sent when clicking on that link, but we would have the same problem when trying to load this resource using an
iframe or an
img if we wanted to share an image. This happens because with
Lax only those cookies on top-level requests are sent: those that imply a change of the URL in our browser.
SameSite attribute is widely supported by browsers, that started in some cases back to 2016. Those that support this act as expected, as long as this attribute (and the
Secure one) is correctly set.
A New Behaviour
Despite of the fact that these security measures have been available for a long time for web developers, they were not adopted specially fast. To make the adoption of the
SameSite attribute easier, browsers have been preparing for a long time the transition towards a new cookies behaviour that helps improving security and privacy on the web. By May 2019 the Incrementally Better Cookies proposal was released, with 2 main points:
- To consider cookies as
SameSite=Laxby default. In other words: if the
SameSiteattribute is not set or valid, the default value will be
- Those cookies set as
SameSite=Nonemust also be set as
Secureto enable their transference among sites.
All browsers have started adopting these behaviour measures by default, but Google Chrome has taken the lead with a detailed roadmap and timeline. The transition in this browser has taken place from October 2019 to August 2020, with the release of Chrome 84 (including a short moratorium because of the recent pandemic).
💡 Note: in fact Chrome still has exceptions for those cookies without the attribute
SameSite set less than 2 minutes ago, allowing that they are sent under
POST top-level cross-site requests. This option, known as
Lax + POST, will be disabled in a future soon, though there is not a date set for this yet.
We can check the new cookies behaviour in our browsers by using a tool such SameSite 🍪 Sandbox.
This way we will see that Chrome is the only browser so far that follows all the rules in this new behaviour, rejecting those
SameSite=None cookies without the
Secure attribute, which is what could cause a fail in a web or integration.
Other browsers do not implement these rejections yet when it comes to creating cookies , so it is still possible to send a third-party cookie without the
So far, these other browsers only warn developers, telling them that if they do not apply these new rules, cookies affected will stop working in future versions:
The rest of browsers based on Chromium/Blink give some additional information when finding trouble cookies:
To sum up, this new behaviour speeds up the adoption of new basic security measures that have been available for long. And to reinforce internet security is always a good idea.
What should you do? If you manage webs that use their own cookies or may have a third-party social-login/sign-on (one of the most common scenarios), you should check as soon as possible that you have your cookies properly set, in case you have not done this yet. Your Chrome users, and soon all the rest too, will thank you for that.
The Cookies They Are a-Changin’ 🎶