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.
I just heard of this a couple weeks ago and almost got bit by it.
I was reading the console.log while debugging some code with the Opera browser and it contained a message warning me they were going to implement it in just a few weeks.
For me it had to do with delivering .js app code from one server that connected to a CouchDB server running on a different vps, so the impact would've resulted in users calling and me having no clue about why things were broken.
I don't know how I missed hearing about it before but the CouchDB team had already done what was needed on their end. Finding out how to implement it was a bit difficult for me though, but I got lucky when someone brought it up on the CouchDB users email list and their message pointed me to what I needed to do. I generally just glance at those emails.
I suppose I ought to bookmark web.dev and make a point to visit it. Thank you for sharing that link dmix.
This is appreciated. This change did break some things for me, and I've been scrambling to understand what SameSite cookies are and how this affects things.
Thanks for the link! web.dev was the first resource I turned to, and it had some excellent articles on the topic. Though I'm now onto more complex topics like "cookie passing when submitting a form in a third-party iframe".
Amusingly, I was bit by this today because of some issues that required Cisco's secure email service: opened the attached HTML file, but couldn't log in, since they haven't added support for Same site.
Found a workaround, but I'm glad they're doing this for the duration.
Everything I read about the original change gave me the impression that it's all backward compatible with earlier versions of Chrome. If you have already made the require changes there's no reason to roll anything back or undo do any work.
17 comments
[ 0.20 ms ] story [ 43.1 ms ] threadMozilla did the same for their TLS 1.0/TLS 1.1 change: https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-a...
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.
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 ?
But rolling it back is fine if they're going to go through with it later.
In php.ini, this is as easy as
I was reading the console.log while debugging some code with the Opera browser and it contained a message warning me they were going to implement it in just a few weeks.
For me it had to do with delivering .js app code from one server that connected to a CouchDB server running on a different vps, so the impact would've resulted in users calling and me having no clue about why things were broken.
I don't know how I missed hearing about it before but the CouchDB team had already done what was needed on their end. Finding out how to implement it was a bit difficult for me though, but I got lucky when someone brought it up on the CouchDB users email list and their message pointed me to what I needed to do. I generally just glance at those emails.
I suppose I ought to bookmark web.dev and make a point to visit it. Thank you for sharing that link dmix.
https://web.dev/samesite-cookies-explained/
Found a workaround, but I'm glad they're doing this for the duration.
Is my understanding correct?