Google is making changes to the way that it handles third party cookies. The changes increase security and user privacy, but could result in some nasty bugs. Are you prepared?


With over 70% market share, Chrome is the most popular web browser on earth. Its meteoric rise to the top over the past few years has been nothing short of incredible. Google now maintains a near monopoly over browser behaviour, and whatever they do will be watched closely as other browsers are likely to follow in their path.

One particular issue has been gripping the headlines recently, and that’s Google’s decision to tighten control on third party cookies. So what are these changes, and how will they affect your applications? Let’s explore.

Why is Google tightening controls on third party cookies?

A cookie is a piece of data set by a web application and stored on a users browser. These pieces of data are often used as unique identifiers so that individual user state (such as being logged in) can be tracked.

There are two main reasons that Google is implementing this change.


Third party cookies are pieces of data set by websites that the user hasn’t directly visited in their browser. For instance, a website may embed an <iframe> element in their page for the purpose of advertising.

In-page advertisements typically utilise third party domains 

In this example, we can see that the user never actually visits, but content is requested from it nonetheless. In this case, if were to set a cookie in response to a request like this it would be considered a third party cookie, which may be used to track the user across multiple websites and observe their unique behaviour.

As you can see, this has all sorts of privacy implications because people generally don’t want anyone else to know what their browsing history is. In response to public sentiment, Google is stepping up to the plate and making it much more difficult for users to be tracked across the web.


Cross-Site Request Forgery (CSRF) is one of the most common, and devastating attacks performed against web applications today. It involves taking advantage of the Browsers notion of trust to perform illegitimate actions.

There are many different ways that this can be exploited, but it is commonly used to attack unsuspecting individuals on shady sites by sending requests to legitimate applications they are logged into and retrieving the responses.

Successful CSRF attacks can have wide ranging implications depending on the target, and Google knows this all to well as they have been the target of a few such attacks in their past.

Changing the Browsers trust model will allow Google to tighten Chrome’s protections against CSRF attacks by preventing legitimate users from sending authenticated requests to websites they trust (like, from websites they don’t trust (like

What are the changes?

Starting in Chrome 80 (dropping sometime in February 2020), Google will begin to block all third party cookies that are not specifically marked as such using the following two options:

  • SameSite=None
  • Secure

These two options denote that a cookie can be sent in a third party context, and only over HTTPS.

Requiring that developers put these flags on their third party cookies means that Chrome will allow users to have finer grain control over which cookies can and cannot be set on their devices. This puts total privacy control into the users hands, and is definitely a change for the better!

How will this affect my applications?

This change will affect any applications that interact with third party domains. If those applications rely on third party cookies, it is likely that without changes they may break.

Examples of systems likely to be affected:

  • Identity/authentication such as third party OAuth2 providers
  • Embedded advertising
  • Embedded content shared from other sites, such as videos, maps, code samples, and social posts.
  • Widgets from external services such as payments, calendars, booking, and reservation functionality.
  • Widgets such as social buttons or anti-fraud services that create less obvious <iframes>.
  • Remote resources that rely on cookies being present such as <script> elements

This is not an exhaustive list, so the best way to check if this will affect you is by:

  1. mapping out the dependencies of your application from a domain perspective
  2. testing each piece of third-party dependant functionality with the following two Chrome flags enabled:
A dependency map of domains used by

What can I do to ensure my users aren’t affected?

If you’ve identified a system that breaks with the above chrome flags enabled, you should ensure that you update the application code relating to the affected cookies so that they comply with the new requirements.

Updating the code may seem as simple as changing the SameSite property to None and setting the Secure flag, but unfortunately things are not as straightforward. Older browsers are not prepared for this change, and the following browsers will have serious issues with the new requirements:

  • Safari on iOS 12 or lower
  • Safari on macOS 10.14 or lower
  • Chrome 51 to Chrome 66
  • UC Browser on Android prior to version 12.13.2

If any of these browsers are given the SameSite=None property, they will reject it and set a SameSite=Strict property instead (see here for more info). This is far more likely to result in a severely broken experience for these users.

The recommendation from Google and others to handle this case is to set two cookies (for every single cookie that you would have set), one with the new flags and one without. On subsequent requests you should check for the cookie with the flags, but fall back to the legacy cookie without the SameSite and Secure attributes. For example:

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

Wrapping up and further reading

So what have we learned?

  • Google is changing the way third party cookies are handled in Chrome to increase user privacy and security
  • The changes are taking place in February 2020
  • It is likely to break some legitimate applications until they are compatible with the new requirements, but results in increased user privacy controls
  • You should check to ensure that your applications are not affected
  • If you are affected, the fix involves setting two cookies to handle the legacy case of broken browsers

If you’d like to read more on this issue, we recommend reading the excellent blog post by Auth0 and Google’s recommendations to handle the change.