Hacker News new | ask | show | jobs
by jacobparker 2268 days ago
Mostly, if you opt in: https://caniuse.com/#feat=same-site-cookie-attribute . SameSite=Lax will still send cookies for some types of GET requests, depending on the complexity of your site and UX there are ways to be more protected (with SameSite=Strict, cookie pairs etc.)

Once all browsers behave like Chrome is trying to (SameSite=Lax by default) we will have dramatically less CSRF on the web. Other browsers are likely to adopt this change eventually if Chrome sticks with it. You will at least need to consider users with out-of-date browsers for a while yet (and implement XSRF tokens and/or explicitly opt-in to Lax/whatever).

The old behaviour will still (and always?) be around with SameSite=None. It has uses, but misuses could create CSRF vulnerabilities. There will still be CSRF problems on the web but it will get a lot rarer and, mercifully, not the default.

1 comments

This API is a disaster. None is insecure, but Lax is private?

Lax and Strict are adjectives. What are they even modifying? Not "SameSite"! They are referring to "SameSiteRestriction" or something.

Why not align with CS of CSRF as AllowCrossSite, and values Always / OnUserRequest / Never ?