SameSite Cookies: why some cookies have stopped working

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 SameSite attribute.

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.

The SameSite Attribute

First of all, I would like to explain briefly what both the SameSite and 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=Strict will 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 https scheme.

What it the real difference between Strict and Lax options?

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.

With the 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.

The 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:

1. To consider cookies as SameSite=Lax by default. In other words: if the SameSite attribute is not set or valid, the default value will be SameSite=Lax.
2. Those cookies set as SameSite=None must also be set as Secure to 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 Secure attribute.

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:

Conclusions

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’ ?