This Set-Cookie didn't specify a "SameSite" attribute and was default to "SameSite=Lax" - Localhost

Question

I'm a front-end developer working on an application where the login/ response put a Session-Cookie on the client. The later request will be authorized since the user "logged in".

Starting from Chrome 80

All cookies without a SameSite attribute will be treated as if they had SameSite=Lax specified. In other words, they will be restricted to first-party only (server and client on the same domain). If you need third-party cookies (server and client on different domains), then they must be marked with SameSite=None.

Restricted to first-party by default

Set-Cookie: cname=cvalue; SameSite=Lax

Allowed in third-party contexts

Set-Cookie: cname=cvalue; SameSite=None; Secure

For my application, I want the default behavior. My client and server running on the same domain in production. But in development I'm working from localhost (different domain).
Up until now, chrome had special flag under chrome://flags - SameSite by default cookies. I could Enable this flag on my development machine and the login passed. And in production, I didn't need this flag because I wanted the default behavior.

Starting from Chrome 91

The SameSite by default cookies flag was removed. This means that from this version I can't login into my app, without deploying it to production.

Does anybody knows how can I get the Session-Cookie while working from localhost. But still keeping the security of SameSite=Lax. If possible with client only changes, but if needed also with server changes.

Chrome DevTools - SameSite error message

Chrome 80 Flags menu - These flags removed in Chrome 91

Update

I tried to solve this by making the server use SameSite=None (development only). This causes a different error: Connection isn't secure. This is because when using SameSite=None you are required to add the suffix Secure and of curse use HTTPS connection. Secure connection has its own problems like having to pay for a Certificate in development.

Answer 1

Check if your cors origin ip are correct or wrong, any spell mistake

app.use(cors({
   origin: [process.env.ORIGIN,process.env.LAN,process.env.WIFI],
   methods: ['GET', 'POST', 'PUT', 'DELETE'],
   credentials: true
}));

whether your frontend ip and cookie domain are same or not.

Answer 2

In my way, i use http-proxy. By the way http proxy is out of box in vite or webpack.

Answer 3

Encountered the same problem recently and found an easy solution that worked for me: local-cors-proxy: https://github.com/garmeeh/local-cors-proxy

Just install it with npm i -D local-cors-proxy and add a command to the package.json:

"scripts": {
  "proxy": "lcp --proxyUrl <REMOTE_DOMAIN> --port <PROXY_PORT> --credentials --proxyPartial= --origin http://localhost:<FRONTEND_PORT>"
}

--proxyPartial= is because by default lcp adds prefix /proxy to the path. Not sure why it's default.

if you need to send cookies, the following two commands are essential: --credentials and --origin http://localhost:<FRONTEND_PORT>

if you omit --origin then lcp will set Access-Control-Allow-Origin to '*' and browser will complain Credential is not supported or something like that.

Then you just run npm run proxy and access the server from http://localhost:<PROXY_PORT>

Bersan already suggested to use proxy but in this case you don't make your frontend connection HTTPS and also don't need to set special values for cookie attributes SameSite and Secure.

Answer 4

If you want to perform "unsafe" CORS requests (which means performing a POST/PUT/DELETE request) you will need to modify the tomcat conf/context.xml file, to set sameSiteCookies to "none" instead of "lax".

    ...
<!-- default samesite cookies configuration, for CORS set sameSiteCookies to "none" and configure bundle for HTTPS  -->
<CookieProcessor sameSiteCookies="none" />
...

Answer 5

As of Chrome v107 (Nov 2022)

I had a similar issue, spent a few hours digging, and what I found is that the only solution for Chrome is to make your front-end connection secure, ie https (using a proxy for instance): Link

An alternative solution is to use Firefox and set: about:config > network.cookie.sameSite.noneRequiresSecure=false. This allows SameSite=None; Secure=false

Answer 6

I have found a way to fix it and share it with everyone :-)

Description appears in the issues section:

Specify SameSite=None and Secure if the cookie should be sent in cross-site requests. This enables third-party use.

In the Developer Tools section, go to the Application tab, and on the left side to Cookies:

The cookie that you want to share with other domains, mark the Secure check and in Samesite put None. Update the site tab locally and you will be able to use the cookies that allow you to send through the domain of origin

I hope this brightens your day

Answer 7

You can set the SameSite attribute manually to "None" + tick "Secure" inside the devtools for development.

That way you would not have to modify your production environment (keep the cookies as SameSite=Lax).

Answer 8

Workaround: Downgrade Chrome

This is not a solution! just a temporary workaround for anybody like me how got his work halted due to this update.

• Uninstall Chrome Go to "Add or remove programs" and uninstall Chrome. Notice that user data like cookies and saved browser passwords may be lost.
• Download Chrome v90 from slimjet.com, or from any other site. Then install Chrome.
• Prevent auto-update Chrome, according to this StackOverflow solution:
  open C:\Program Files (x86)\Google\Update
  rename the file GoogleUpdate.exe to GoogleUpdate2.exe.
  This will cause Chrome to not find the update package.
• Update Flags - Open Chrome and type: chrome://flags
  Search #same-site-by-default-cookies and Disable the flag

Answer 9

In our case, we are able to also run our server locally on a different port and point our client app to that localhost address for development purposes.

For example, I have the client app running on localhost:1234 and sending requests to a local copy of the server running on localhost:5678. This ensures that cookies are set successfully since the client and server are now "SameSite".

Admittedly, this is perhaps more of a workaround than a solution, but I hope it helps in the short term.