SameSite Cookies and New Behavior in Chrome 80

To understand how this could impact you, let’s first discuss what the SameSite flag means.

The SamSite scenario

Consider the following scenario involving two different sites: othersite.com and yoursite.com. As you can expect, you’re in control over yoursite.com, while othersite.com is some other site that has chosen to include contents from your site, as well as link directly to it.

A user has previously visited your site, and logged in. This means that the user’s browser now has a cookie, called yoursite_session. This cookie allows the user to visit your site again in the future, without having to login each and every time.

The SameSite flag

The SameSite flag is relevant when the user visits some other site that fetches resources from your site. This is called a cross-site request. In other words, a cross-site request is a request sent to a server that is different from the site shown in the browser’s address bar. The SameSite flag controls the behaviour with regard to how cookies are sent on cross-site requests. 

There are four possible states to consider for the SameSite flag. It can be set to None, Strict, Lax, and finally it can be missing from the cookie, and thus have no value at all. We’ll start by briefly discussing what the different values mean, and describe what’s changing in Chrome starting with version 80.

When Samsite is set to none

When SameSite is set to None, the browser will always send the cookie together with the request to yoursite.com, for all different kinds of requests. This can be seen in the figure below.

This can be desirable in scenarios where you want your site to be included on other sites, while still keeping track of the user’s session. Consider for example services such as Youtube or Facebook, which can be included in other sites. In these cases it would be annoying for users if they had to login each time content was embedded in other sites.

When SamSite is set to strict

When set to Strict, no cross-site requests are allowed. This means that, if another site tries to include an image, script, or document from your site, the user’s browser will not send a cookie together with the request. As can be seen in the figure below, this means that the cookie won’t be sent for any of the two requests in this scenario.

Note especially that this also includes links going to your site. As a practical example, if the user is logged in to your site, but tries to access it through a link from another, external site, the cookie will not be sent with the request, and the user will not be considered logged in. This prevents CSRF attacks very effectively, but in certain cases it can be a bit too restrictive.

For example, if a user clicks a link to the Debricked tool, Github, Gitlab, or most other sites, they would expect to be logged in to the site when they arrive. This would not be the case using the Strict setting.

Lax

Lax is provided as an option when Strict is deemed too restrictive, but you still want some protection against CSRF attacks. In this mode, cookies are not sent in most cases, for example, cookies will not be sent when, e.g., images or scripts are requested from another site. The difference is that for top-level navigations, for example when the user clicks a link to navigate, cookies will be sent. See the figure below.

In this case, again using a link to the Debricked tool, Github, Gitlab, or most other sites as an example, the user would still be logged in to the site when they arrive. In this way, Lax can be seen as a compromise between the Strict and None values.

What if SameSite is not set at all?

What if you simply don’t include the SameSite option in the cookie at all? What will happen? Traditionally, and in other browsers (as of now), this would correspond to a SameSite value of None. Thus, up until now a missing SameSite value would cause the browser to send cookies with all cross-site requests. But things are changing with the arrival of Chrome 80.

What’s changing in Chrome 80?

In Chrome 80 the behaviour when SameSite is missing will no longer default to None, but rather to Lax. In addition, Chrome 80 will also require that cookies which have SameSite set to None also sets the Secure flag.

This means that if you’ve previously relied on the previous default behaviour, i.e., that cookies are sent with every request to your site, you will need to set the SameSite flag to None explicitly. In addition, you must also send the request over an encrypted connection. If you miss this, your content may no longer function correctly when included on other sites, at least if it depends on cookies being sent with the requests.

Why is this change implemented?

While changing the default behaviour in a backwards-incompatible way might seem like a drastic move, the purpose is to increase the security on the web. The previous behaviour required developers to explicitly enable the SameSite flag to protect against CSRF attacks, while the new behaviour provides a more secure default behaviour. It is also worth noting that there are plans to implement the same behaviour in Firefox, even though it is not done yet.

What can Debricked do to help?

Need to get up to speed on web security technologies? Do not hesitate to contact us at Debricked. We have long experience in several areas of cybersecurity and can provide professional education and training.