Update CSRF info in Sessions page's "Client storage" section

[mahmoud]

Hey, really loving the book! I did notice on section that seemed a bit out of date.

Similar to #12, CSRF can be mitigated on 96%+ of browsers by using a dual cookie method described here.

The current page reads:

CSRF protection must be implemented when using cookies, and using the SameSite flag is not sufficient. ... Lax should be preferred over Strict for the SameSite attribute as using Strict will cause the browser to not send the session cookie when the user visits your application via an external link.

I suggest updating this to be in line with the changes in #15, and ideally linking citations.

[pilcrowonpaper]

That's still 4% of users not protected, and as mentioned in the book, SameSite doesn't protect you from cross-origin request forgery

[mahmoud]

Well, that's a very shallow reading of the 96%+. What it means is 100% of Chrome, Safari, Firefox, etc., are protected. And 100% of Opera Mini, Baidu Browser, etc., aren't protected.

Realistically, many sites won't work with those browsers for a variety of other reasons, including limiting the target market. For instance, I'm certainly not building a product for the Chinese market, so I need not worry about QQ and Baidu browser.

As for the second part, maybe some clarification is necessary: Are you recommending that CSRF tokens be implemented as the primary line of defense to prevent CORS attacks as well? If so, maybe this could be clearer in the CSRF doc.

[pilcrowonpaper]

No, cross-origin request forgery is not CORS. It’s a (admittedly rare) attack where an attacker gets hold of one of your subdomains.

[pilcrowonpaper]

I’m not really sure the different between tracked and all-users on caniuse but even if the number is 99% or 99.5%, that’s still 1/100~1/200 users not protected. Of course that might be something you’re fine with (alongside the cross origin stuff) and we could probably mention it, but I’m not sure what issue you have with our general recommendation