It’s Time To Properly Secure Your Cookies
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
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:
Cookie will only be sent if the site for the cookie matches the site currently shown in the user’s browser URL bar.
Allows the cookie to be included along with top-level navigations. For instance, following through a link from another website leading to your domain.
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
SameSiteattribute 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
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
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
Strict, as stock browser behavior cannot be relied upon – not all browsers offer the same protection as Chrome does.
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.
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
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:
- 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.
- Detect client via User Agent string before sending the
Set-Cookieheader. 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.
- Go to
chrome://flags/and search for
- Enable the following flags:
- Go to
about:configand search for
- Turn on the following flags:
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
- 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.