Session cookie set `SameSite=None; Secure;` does not work

Question

I added SameSite=None; Secure; to set-cookie. but the cookie was not set and I can’t log in to my site.

response.writeHead(200, {
  'Content-Type': 'application/json',
  'Set-Cookie': 'token=' + token + '; SameSite=None; Secure; Expires=' + time.toUTCString() + '; Path=/' + '; Domain=' + hostname,
  'csrf-token': csrfToken
});

I reviewed the cookie in developer tools under Application>Storage>Cookies and see more details. it showed a warning message:

this set-cookie was blocked because it was not sent over a secure connection

chrome blockes cookies, Because I work on the development environment and i send http request. But this test on Firefox browser logs in correctly.
I put the word secure inside the cookie and it worked properly, but because the word secure must be used next to samesite = none for cross-origin, otherwise the cookie will be blocked.
My question is why when I use secure, only the Chrome browser blocks the cookie, but it is true in other browsers. And that if I do not use secure I can not test the payment gateway because it blocks Chrome cross-orign if I do not use secure...

Kamala

"it was not sent over a secure connection". "secure connection" here means https schema, and the cookie is not accepted with http schema. – Lacrosse

Answer 1

My question is why when I use secure, only the Chrome browser blocks the cookie, but it is true in other browsers

I am not sure about other browsers but Chrome implements strategy of allowing cookies with secure attribute over secure connection as per this IETF draft.

While this draft is implemented for Chrome, it is not on Firefox which is why on Firefox in you go to about:config > network.cookie.sameSite.noneRequiresSecure, default value is false.

If you just need to do it for your local dev environment, You can retain the old behavior for cookies in chrome by disabling

1. chrome://flags/#same-site-by-default-cookies
2. chrome://flags/#cookies-without-same-site-must-be-secure

I have to support legacy http clients, but if I make https:// origin secure , I can't set cookie from http, more over I can't access this cookie from http, my goal is to have SameSite=None, Secure on http and not secure on http:// origin, any ideas, instead of establishing protests near google office ?

Given that it is going to be standard in near future, I doubt you will be able to achieve this behavior for client applications, only route is to go secure, HTTPS.

Reference:

1. https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite
2. https://redmondmag.com/articles/2020/01/28/samesite-cookie-changes-break-apps.aspx

Bondon

The problem that I can't update clients which uses http, and can't redirect them. The "secure" attribute, makes cookie unusable on http origin, which is wrong i guess, i think it should allow to set separate "non secure" cookie in different storage. – Woodworth

I'm trying to send cookie cross site via payment gateway using header('Set-Cookie: cookie2=value2; SameSite=None; Secure', true); But once the payment is complete and user gets back to product page to order again, payment is getting done but the cart data (session) is being block by chrome. I don't understand what's wrong. – Chretien

Not sure what do you mean by session is being blocked by chrome. Are you seeing cookie using developer tool? Do you have a site that I can take a look at? – Bondon

Support for the same-site-by-default-cookies or the other flag on Chrome was removed, so the solution now is to use firefox piunikaweb.com/2021/06/14/… – Whalebone

Answer 2

Sometome cookies wouldn't work as expected because Some cookies are misusing the sameSite attribute. Cookie SomeCookie rejected cause of it has the sameSite=none attribute but it is missing the secure attribute. So any cookie that requests SameSite=None must marked as Secure.

Set-Cookie: product=pen; SameSite=None

For fixing this, you must add the Secure attribute to your SameSite=None cookies.

Set-Cookie: flavor=choco; SameSite=None; Secure

A Secure cookies will only sent to the server with an encrypted request over the HTTPS protocol.

Note: insecure sites (http:) can't set cookies with the Secure directive.

Certes

what to do if I just want to make my cookie continue to work in future chromium releases the same way as before (regardless secure, be crossdomain) ? – Woodworth

I think the official answer to your follow up question is "get the clients off HTTP", they really don't want to keep supporting non-SSL connections – Heshum

thanks for the Note. Any way though of making this work with http:<IP>:<PORT> on development? – Forbade

but i dont have https for my local development setup, how am I supposed to set a cookie if setting a cookie cross-site requires SameSite=None and SameSite=None requires Secure=true, this is ridiculous – Whalebone

Answer 3

so my case was that I was using Paas to deploy my backend logic on it and that Paas was using a load balancer, so when I sent a post request to log in the request was hitting that load balancer first not the server, which then forwards it to one of the application servers. However, when the load balancer forwards the request, it often modifies certain headers like X-Forwarded-For, X-Forwarded-Proto, and others to preserve information about the original client request.

Here's where the issue arises: when Express receives a request, it trusts the information provided in the request headers. However, since the request is coming from the load balancer and not directly from the client, Express might not interpret these headers correctly by default.

so setting app.set("trust proxy",1); solved it and cookies are now set with sameSite:none and secure

Calyptra