CSRF is (really) dead

A little while back I wrote a blog post about how "CSRF is dead". It focused on SameSite cookies, a powerful yet simple feature to protect your website against CSRF attacks. As powerful as it was, and as much as it will kill CSRF, you had to enable it on your site, and that was the problem. Now, we're solving that problem.



SameSite Cookies

To understand the problem of CSRF and the solution that SameSite Cookies provides, you should first read my original blog Cross-Site Request Forgery is dead!. If you want further details on cookie protections you should also read Tough Cookies. The TLDR; there are powerful protections you can put in place to protect your users/visitors but you have to go and turn them on, they're opt-in mechanisms. In the perfect world you'd enable SameSite by adding SameSite=Lax to your cookie, just like the Secure or HttpOnly flags.


Set-Cookie: __Host-session=123; path=/; Secure; HttpOnly; SameSite=Lax


It turns out that not many websites went and added the SameSite=Lax flag to their cookie. [insert sad face here]


SameSite by Default

When SameSite first came out, nobody wanted to make it the default. It could break things, change expected (legacy) functionality and generally speaking the worry of breaking stuff stops us making progress. SameSite was made opt-in, but that's changing.



Mike works on Chrome and I was really happy to see the idea of making security the default on cookies. You can track the Chrome Platform Status for Cookies default to SameSite=Lax and see this is available behind a flag in Chrome 76 (already released) and will be landing in Chrome 78 (very soon). Website operators will need to do nothing to have the powerful protection of SameSite by default, but they may want to test that everything still works as expected using the flag in Chrome now: chrome://flags/#same-site-by-default-cookies


More Secure

As mentioned in the links above, sites can opt-out of the SameSite protections if they need or want to. To do so, sites can set SameSite=None on their cookies and Chrome will respect the setting, but there is one requirement. The cookie must have the Secure flag set! You can track the Chrome Platform Status of Reject insecure SameSite=None cookies but it's available behind a flag in Chrome 76 (now) and looks set to land in Chrome 80 later this year. The logic makes sense and the idea is to protect cookies sent in cross-site requests, that can be tracked and viewed on the network, from being sent over an insecure channel like HTTP. Again, site operators can test if there will be any impact using the flag: chrome://flags/#cookies-without-same-site-must-be-secure


A better way

I like and agree with the stance of having security features like this become the default. If site operators don't want this then they can easily opt-out, but this approach will result in a far higher rate of adoption for these features. Let's hope we can start to take this approach to more features as we move forwards with securing the web!