Google Chrome’s SameSite Cookie Update

It’s a new decade and new security measures are going into effect to protect user’s online privacy. Announced last year and going into effect on February 4th, Google will roll out a new Chrome update (version 80) that limits cross-site tracking by enforcing new default settings for the SameSite cookie attribute.

The SameSite update requires website owners to explicitly label third-party cookies that can be used on other sites. Cookies without labeling won’t work in Chrome browsers with the latest update which could negatively affect a website’s tracking mechanisms.

What is the SameSite Attribute?

The SameSite attribute tells a browser when and how to fire a cookie in first or third-party situations. This attribute prevents the browser from sending the cookie along with cross-site requests in order to mitigate risks of cross-origin attacks.

Give me an example of a Cross-Site Attack

Let’s pretend you’re logged into your banking account through their online portal. Have you ever noticed that some websites will keep you logged in? That’s because of a session cookie – after you authenticate, the website has set a cookie on your browser that allows you to remain logged in. As you’re browsing a different website, you click on a link from a Tweet for a funny video. Unfortunately, that link could be a cross-site request forgery attack (XSRF) that tricks your browser into executing an unwanted action in the logged-in session with your bank.

Before SameSite, clicking on the XSRF link would execute the transaction by piggy-backing onto the session cookie generated from your bank (that keeps you logged in).

After SameSite, the browser won’t allow the cookie to be added to an already authenticated website if the link derives from an external site.

What Are The Types of SameSite Cookie Attributes?

• SameSite=Strict
  • The cookie will only fire if the link is coming from the same domain (first-party) AND the link isn’t coming from a third-party
• SameSite=LAX
  • The cookie will only fire if the domain in the URL bar equals the cookie’s domain (first-party)
  • This is the new default setting as of February 4th
• SameSite=None
  • The cookie data can be shared with third parties or external sites
  • When Samesite=None, an additional attribute, ‘Secure’, must be included as of February 4, 2020.

So what’s changing?

There are two major changes in the Chrome v80 release:

1. The new default behavior for unlabeled cookies is “SameSite=LAX”
2. If a cookie uses the “SameSite=None” attribute, it must also include the ‘Secure’ label. The Secure label means cookies must be set and read via a secure HTTPS connection.

Google’s change means that cookies that don’t include the “SameSite=None” and “Secure” labels won’t be accessible by third-parties in Chrome v80.

Do I need to do anything to prepare for this change?

When you load your website in Chrome, open the Developer Tools menu (Ctrl + Shift + I) and navigate to the Console tab to view any errors regarding SameSite cookies. You should also migrate to HTTPS secure pages if you haven’t done so already.

Updates to CookiePro

By default, first-party cookies will be treated as ‘SameSite=LAX’ which is the desired functionality.

Additionally, CookiePro has created a preview feature to add this attribute to first-party cookies. If you are interested in adding this feature to your account, please send an email to [email protected] and we will enable it for you. Once we add the feature to your account, the change will go into effect after republishing the script.

Cookies Affected:

• OneTrustConsent
• OptanonConsent
• OptanonAlertBoxClosed
• eupubconsent

The third-party euconsent cookie has been updated to SameSite=None and ‘Secure’ as this cookie should be used in the third-party context to relay a user’s consent to other Consent Management Providers.