New SameSite Cookie Policy In Chrome

It’s Time To Properly Secure Your Cookies

Google Chrome browser recently began displaying two warnings inside of its JavaScript Console related to the upcoming changes in cross-site cookie delivery policy. What are these alerts trying to achieve and how exactly does this affect your website?

The first type of warning refers to a missing SameSite attribute on any of the cookies currently attached to the session:

A cookie associated with a cross-site resource at <URL> 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`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

The second type of warning calls attention to third-party cookies with SameSite attribute correctly set to None but without required Secure flag attached to them:

A cookie associated with a resource at (cookie domain) was set with `SameSite=None` but without `Secure`. A future release of Chrome will only deliver cookies marked `SameSite=None` if they are also marked `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5633521622188032.

While at the moment both messages are merely a heads up for developers, changes come into effect quite soon – to be exact, in Chrome v80, which is slated for a stable release in February, 2020.

In the next two sections, I’ll briefly explain the relevant terms and explore the background for introducing this new behaviour. If you’d like to find out how this may or may not affect your website straight away, feel free to skip to ‘Consequences for your website’ section below.

Quick Refresher On Definitions

SameSite and Secure are attributes which belong to Set-Cookie HTTP header. Secure is a standalone boolean value indicating that a cookie must be passed only over a protected connection (HTTPS), whilst SameSite can be equal to one of the following values:

Strict

Cookie will only be sent if the site for the cookie matches the site currently shown in the user’s browser URL bar.

Lax

Allows the cookie to be included along with top-level navigations. For instance, following through a link from another website leading to your domain.

None

Explicitly marks the cookie for cross-domain usage. As of Chrome v80, this value must go hand in hand with Secure attribute to ensure encrypted transmission.

Intentions Behind The Change

The absence of the SameSite attribute causes the vast majority of cookies to be sent in a cross-site context, regardless of the actual intent. This poses certain problems for users and developers alike:

• Browsers have no way of distinguishing between same-site and cross-site cookies, which confines the usefulness of cookie controls. If you erase cookies, everything is wiped completely – including legitimate things like login states and website preferences.
• The majority of anti-tracking tools offer an option to block all third-party cookies. If no proper SameSite attribute is set or is missing altogether, they will inadvertently shut down first-party cookies too. Websites are tethered as a result and you are more likely to run into various malfunctions. On top of that, this blanket approach to blocking of undesired cookies, to no small degree, subverts privacy by incentivizing cagey techniques such as fingerprinting.
• Third-party cookies are widely used for tracking and may contain sensitive data that pertains to user identity. Delivering cookies through non-secure connections facilitates eavesdropping as intruders can easily intercept and, what’s worse, tamper with such requests. In other words, being exposed to CSRF attacks is a status-quo for many developers these days.

Folks at Google put forward a proposal for a set of open standards called ‘Incrementally Better Cookies’ with an intention to fundamentally enhance privacy on the web. The change calls to explicitly define which cookies are permitted to function across foreign domains and encourages embeddable content producers to migrate to HTTPS. This adjustment mitigates certain class of security concerns – specifying SameSite attribute is a reasonably robust protection against CSRF and cross-site injection attacks. It also grants users more granular control over cookies, allowing them to preserve useful settings while doing a cleanup. Last but not least, browsers will be able to distinctly identify and list sites that are setting cross-site cookies.

Consequences For Your Website

Same-(sub)domain cookies

If you manage cookies that are only accessed by the same domain or any related subdomains, there is no action required on your part. Chrome (as of v76), treats all cookies as Lax if SameSite attribute is absent or its value isn’t set. This setting effectively restricts them to be used only within the first-party context by default and makes it possible to automatically shut down any external access attempts.

Nevertheless, it’s strongly recommended to clearly mark you same-domain cookies as either Lax or Strict, as stock browser behavior cannot be relied upon – not all browsers offer the same protection as Chrome does.

Cross-domain cookies

If you currently provide a service that other sites consume, such as advertising or widgets, you will have to do a make-over to comply with the new standard. First of all, you should use SameSite=None attribute along with Secure flag to clearly communicate your intentions about using a cookie in a third-party context. You also need to ensure that your requests are being carried strictly over HTTPS.

Mixed context

Finally, If you have cookies meant to be accessed in both first and third-party context, consider separating them to accrue the security benefits of SameSite=Lax setting.

How To Prepare If You Are Affected?

When making changes to the way you are handling cookies on the server, keep in mind that it’s highly desirable to maintain backward compatibility.

Example of a new Set-Cookie header definition:

Set-Cookie: third_party_cookie_key=value; SameSite=None; Secure

There are two strategies at your disposal:

1. Specify both old and new style cookies simultaneously. Arrange for graceful degradation. The downside of this approach is that every request will be carrying redundant cookies.
2. Detect client via User Agent string before sending the Set-Cookie header. While more efficient, beware that some affected clients could slip through the cracks.

In this repo you’ll find examples on implementing SameSite=None; Secure attributes in a variety of languages, libraries, and frameworks.

How To Test Things Out Right Now

Chrome and Firefox, at the moment of writing, are the only browsers offering experimental support for this feature.

Chrome (v76+)

1. Go to chrome://flags/ and search for samesite
2. Enable the following flags:
   • same-site-by-default-cookie
   • cookies-without-same-site-must-be-secure

Firefox (v69+)

1. Go to about:config and search for samesite
2. Turn on the following flags:
   • network.cookie.sameSite.laxByDefault
   • network.cookie.sameSite.noneRequiresSecure

Conclusion

Stricter SameSite cookie policy aims at improving both privacy and security of the web platform. This is an example of a simple yet powerful change which rapidly became a widespread standard. Hopefully, we will see all major browser vendors continue on their path towards safer, surveillance-resistant web.

Coview: Making Customer Support Effortless

When your web app user is having problems, Coview lets you request a screenshot, a screen recording – or lets you jump right into a co-browsing session with them. 

• There’s nothing for your users to download or install. 
• Users are never tracked without their knowledge.
• No need for them to try and explain the problem – they can just show you.

But best of all, Coview records the entire action at a code level. Meaning you can pause and explore the page as it is in that moment – including being able to inspect code right in the recording.

• Resolve bugs without having to reproduce them
• The source HTML and other code remains unmodified
• Javascript errors are shown with their complete stack trace
• Detailed network performance reports included

This means you can get on with solving issues without having to rely on your non-technical customers to try and explain the error.

Try Coview for free