Get best of the week

SameSite = Lax by default - already in Chrome 80 stable (though not for everyone yet)

The other day, an attentive colleague (thank you, Lena) reported a strange bug - the server normally set cookie in the browser, but it didn’t arrive back. Everything worked the day before, but now the cookie was set, but after a few seconds it magically disappeared (although it should last 24 hours). It was reproduced only by a few people in the team and only in the new Chrome 80, but the rest in Chrome had exactly the same version, everything was in order. In other browsers, everything worked like a clock. Mystic. They started to figure it out, and after some time, the Chrome console noticed a warning for the response header setting the cookie:
A cookie associated with a cross-site resource at _your_domain_ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`.

They began to study what it was, and gradually it became clear how the error arose and why not everyone showed it. Since our service must process requests from different domains, then this SameSiteis just our case. They added SameSite=None; Secure, and the problem was solved for us.

Why is that?


Initially, according to the HTTP standard, the browser sent cookies (or just cookies) for any request to the corresponding domain. This opened up opportunities for a CSRF attack, that is, it allowed unscrupulous people, under a certain set of circumstances, to gain access to some resources under the guise of unsuspecting bona fide ones, simply by using their cookies.

In 2016, an attribute was introduced SameSitethat allows you to control whether the browser will send cookies if the page sends a request to another domain. The developers have the opportunity to block the transfer of their cookies, if the request is executed from a third-party site. For this, the attribute SameSitehad to be explicitly set to Strict.(cookies are transmitted only upon requests and transitions from the domain to which they belong), or Lax (cookies are transmitted upon transition to the site from other sites by a direct link, but are not transmitted upon other requests from them, for example, when an AJAX request or uploading pictures ) The absence SameSitewas equivalent SameSite=None, that is, by default, cookies were still transmitted on any request.

In May 2019, Google Chrome developers announced that they would gradually change this behavior and interpret the absence of SameSite as SameSite=Lax(more here) That is - by default, the browser will block the transmission of cookies for requests from the current page to any other resources, except for direct clicks on the link. Firefox and Edge developers have announced that over time, they will also implement this change in their browsers.

For users, this browser behavior is more secure. Developers of sites and web services need to keep in mind that if they still need to receive their cookies when requesting from other sites, they will have to explicitly set their cookies attributes SameSite=None, Secure( Secure- because such a request, in addition, should only come to the server via a secure channel )

Since the innovation changes the current standard, and not all sites will be able to adapt quickly, the transition to a new behavior occurs gradually. Initially, it was turned on for a limited number of Chrome beta users, and now their number is gradually increasing. Actual information is available here . The latest entry on the link:
Last updated March 9, 2020.

We have begun enforcing the new behavior for Chrome 80 stable, just not for 100% of users. The controlled rollout is to a limited initial population,
That is, the beta testing period is behind, and Chrome developers have begun to slowly include new functionality among ordinary users. Which is good in principle, since it is really safer.

You can restore the old behavior through the settings : in the Chrome address bar, enter chrome://flags, go to the page, find the SameSite be default cookies item , and set it to Disabled . But this is more suitable for testing than for ordinary users. Similarly, if your Chrome 80 is still running the old behavior, you can force the new functionality by setting the same setting to Enabled .

Therefore, if your site needs to receive cookies when requesting from different domains - be prepared for the upcoming changes (and whoever is ready is good for that). Good to all!

Added by:
xdenserindicated in the comments that some older versions of browsers do not support SameSite=None, not accepting such cookies at all or processing them in a non-standard way. Among them are browsers for desktops and mobile devices. The page https://www.chromium.org/updates/same-site/incompatible-clients provides a list of browsers and a possible solution to the problem (in pseudo-code, but quite detailed). The authors suggest detecting problematic versions of browsers by title useragent, and not setting their cookies attribute SameSite=Noneat all.

Added 2:
In connection with the situation with COVID-19, from April 3, 2020, Google temporarily suspends the implementation of the described changes in the processing of SameSite, to ensure the smooth operation of Internet services. On devices where changes are already applied, they will be canceled.
(c) blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

Sources:
web.dev/samesite-cookies-explained
www.chromium.org/updates/same-site
www.chromestatus.com/ feature / 5088147346030592
www.chromium.org/updates/same-site/incompatible-clients
blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

More articles:


All Articles