Recently, Chrome changed the policy for whether cookies are attached to cross-origin requests. Now, cookies are not attached to cross-origin requests unless:
SameSite
cookie attribute is either Lax
or None
and the request was initiated by a user action, orSameSite
cookie attribute is None
and the Secure
cookie attribute is true
, meaning that the cross-origin request has to use the https
scheme.(The above is not wrong, but it is slightly simplified. Here is a more thorough writeup.)
In my development environment, I use a tool to compile my development language and hot-reload the changes into my browser tab. This tool serves the frontend code on its own port, and the backend is served on a separate port by a separate process, so we're dealing with cross-origin requests from browser to backend. Naturally, both the frontend and backend are served from localhost
with scheme http
. And many of the requests that the frontend app makes are not initiated by user action yet still need cookies for auth purposes.
As a result, anything requiring cookies will not work in my development environment. (Yeah, spent quite a while figuring that one out…)
My question is: how can I bypass, work around, or disable these SameSite
cookie security restrictions for my development environment in an easy way that won't decrease my security as I'm browsing other sites?
It would be nice if, for example, there was a way to add localhost
to a whitelist of origins in my browser that allowed SameSite=None
cookies even without a Secure=true
attribute. Slightly less nice, but still acceptable, would be an easy way to wrap or proxy my http://localhost:<port>
services so that they can be accessed via the https
scheme. Or perhaps there's another approach using some obscure cookie magic.
Update 2021-09-16: @tommueller points out that this question is related. This question is different in that it talks about a [cross origin but] same site situation, where both origins are from localhost.
Fixing common warnings The warning appears because any cookie that requests SameSite=None but is not marked Secure will be rejected. To fix this, you will have to add the Secure attribute to your SameSite=None cookies. A Secure cookie is only sent to the server with an encrypted request over the HTTPS protocol.
You can disable them through chrome://flags Cookie Deprecation messages disabled.
Those who wish to disable the said SameSite flags can do so by adding –disable-features=SameSiteByDefaultCookies or –disable-features=CookieswithoutSameSitemustbesecure in the Target field of the Google Chrome or Microsoft Edge properties and restart the web browser.
Enable the new SameSite behavior If you are running Chrome 91 or newer, you can skip to step 3.) Go to chrome://flags and enable (or set to "Default") both #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure. Restart Chrome for the changes to take effect, if you made any changes.
If all of your development environment is hosted under localhost
then requests between different ports, while cross-origin, still count as same-site. See: https://web.dev/same-site-same-origin/
In your development environment, you can either drop SameSite=None; Secure
completely or explicitly set SameSite=Lax
.
Alternatively, look at creating self-signed certificates for localhost
or local vms to better match your production environment - though that's slightly more involved.
At the time of this writing, Firefox does not default same-site
to lax
when unspecified, but Chrome does. This flag can be disabled in Chrome here, but warning that this disables the flag for all sites you visit, not just your development site.
chrome://flags/#same-site-by-default-cookies
Source: https://www.chromium.org/updates/same-site/faq
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With