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:
- 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-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+)
- Go to
chrome://flags/
and search forsamesite
- Enable the following flags:
same-site-by-default-cookie
cookies-without-same-site-must-be-secure

Firefox (v69+)
- Go to
about:config
and search forsamesite
- 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.