Chrome browser pushes SameSite cookie security overhaul

Slowly but steadily, web developers are being given the tools with which to tame the promiscuous and often insecure world of the browser cookie.

The latest big idea is an IETF standard called SameSite (aka RFC6265bis), which Google and Mozilla have promoted since 2016 and the former announced this week it will start pushing more aggressively in Chrome from version 76 this July.

Cookies look simple on the surface – they’re a little chunk of text data that a website can ask your browser to remember, and that your browser will return to that website whenever the browser fetches a page, image or anything else from it. As a security measure, cookies can only be handed over to the domain that set them.

The most common use for cookies is user identification – a site stores an ID in a cookie and the browser returns that ID with each request, so that the site knows who it’s talking to. It’s this simple technique that allows sites to provide authentication and personalisation.

What gives cookies a bad name are third-party cookies, usually put there by advertisers or social media giants as a way of tracking users across sites.

For example, if a user visits a page on with a Facebook button on it, their browser fetches that button from as the page is loaded. As with any HTTP interaction, the browser will include any cookies in the request to Facebook, along with a referrer header saying what page on the request is coming from.

If you happen to be logged into Facebook (and even sometimes if they aren’t), that request for a button reveals to Facebook who you are, which page you visited and when.

If a social media or advertising company can persuade enough sites to include code hosted on a domain they own, they can turn these cookies into cross-site trackers that build up a map of each user’s behaviour and interests as they browse the web.

And that’s why some users regularly clear them from browser caches or resort to ad blocking or privacy plugins – clunky but effective solutions that can stop sites working correctly.

The consequences of this behaviour aren’t limited to tracking, it can also lead to major security hazards such as Cross-Site Request Forgery (CSRF) attacks.

To simplify, if a user leaves a site (a bank, say) without logging out, in theory it’s possible for a second, malicious, site to fool that user into making unseen requests to the bank that exploit the fact that the user is still logged in.

Perhaps the biggest flaw in this architecture then, is the assumption that just because a browser can hand over a cookie, it should.

How will SameSite help?

Adding SameSite support to Chrome (Firefox, Safari and Edge added experimental support last year) will require web developers to control cookies using the SameSite attribute of the Set-Cookie header, which can be Strict, Lax, or None.

In effect, these are a way of controlling which cookies can be sent by the browser and under what circumstances, doing away with the notion that a browser should send a site a cookie just because it can.

A cookie set to Strict will only be accessible when you’re visiting the domain that set it. If you visit a different site where content from that domain is included, the cookies will not be sent home.

The Strict setting is also a long-overdue way to counter the risk of CSRF attacks.

Alternatively, setting Lax will allow cookies to be made available to third parties via HTTP GET requests, but not by other methods such as POST. This won’t be enough to block a lot of tracking but it will blunt CSRF attacks.

Finally, there’s None, which simply allows a cookie to be accessed in the same way it is today.

Good news for security and, with fewer cookies flying around, privacy too. Cookies will be either same-site and restricted or one of two states of cross-site.

Commented Google’s director of Chrome product management, Ben Galbraith:

It will also enable browsers to provide clear information about which sites are setting these cookies, so users can make informed choices about how their data is used.

Google would also look to limit cross-site cookies where SameSite=None to HTTPS connections as a way of further boosting the privacy effect, he added.

Because Google, unlike many advertising rivals, has little to lose from SameSite (i.e. the popularity of Chrome and Google’s ubiquitous services, including DoubleClick ads), there’s controversy about its intentions.

It’s another example of the internet’s privacy paradox – big tech companies seem happy to promote privacy so long as it doesn’t stop them peeking behind the curtain.

Reforming cookies will also take more than inventing new cookie attributes. Today, most sites set cookies without a SameSite attribute and it will take some time for them to support the new format.

Chrome 76 offers a hint of how Google might hurry that process along. It introduces a cookies-without-same-site-must-be-secure flag that users can set so that Chrome assumes all cookies without a SameSite value are set to SameSite=Lax.

If Google applies the approach it took to HTTPS adoption to cookies, we can expect to see that flag being set by default, and the value ramped up, in later versions.