sameSite no longer defaults to 'None' when undefined
JulietAdams opened this issue · comments
Hello, the team I am on is currently building a new UI and we have several services we proxy to via an auth0 gateway. At this gateway we create a cookie session using this package. I recently was doing some dev and made a cross origin request when I noticed this warning in the js console:
"A cookie associated with a cross-site resource at <myappurl.com> .was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032"
If you check out those links you'll see that the chrome spec for setting sameSite to undefined has changed from sameSite defaulting to 'None' to 'lax' instead.
In your docs the options for sameSite are said to be T/F, ‘strict’ or ‘lax’. Now previously we have not been setting sameSite so its defaulting to false, but from the warning and checking the cookies via dev-tools in our apps we can see that it does not actually set the sameSite value to ‘None’. So there is now essentially no way for us to now set sameSite to none using this package. It totally makes sense why these would be the options, since prior to this spec change by google an undefined sameSite would mean the browser sets it ‘None’. But is going to be an update to change it to avoid breaking changes when chrome updates?
Additionally, the case could also be that we are totally misunderstanding this warning and the functionality of your library, I just didn’t see anything in the src that led me to believe that you are manually setting sameSite to ‘None’ when the value is undefined and instead letting it be set by the browser.
Hello! So there are a couple things here.
(1) Yes, I will be updating the library soon to enable setting the attribute to None.
(2) No, that won't happen automatically because not having the attribute set and having it set to None is actually different behavior. This is especially the case as older Safaris will actually ignore the entire cookie is sameSite=None is set on the Set-Cookie header, which means if you would need to set it to None, you'll need to make sure you test in the browsers and versions which you need to support.
It is ultimately Chrome that is making the breaking change and breaking from the web standard (https://www.chromestatus.com/feature/5088147346030592), and this module suddenly including the attribute set to None breaking existing clients who follow it (like Safaris) is itself also breaking behavior.
Thanks for being so fast and for clarifying the differences in behavior as well. We're aware of the safari issue with sameSite='None', and I think we'll just say screw it since most of our users and dev team use chrome and occasionally IE/Edge.
Yep, that was just regarding the module producing a cookie with it set by default. The underlying library that does the cookies is releasing a version with "none" support later today, at which point this module will release a new version with the updated underlying library.
Version 1.4.0 has been published which supports setting sameSite to the 'none' value.