33

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 DevTools - SameSite error message

Chrome 80 Flags menu - These flags removed in Chrome 91 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.

Gil Epshtain
  • 8,670
  • 7
  • 63
  • 89

6 Answers6

4

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

Bersan
  • 1,032
  • 1
  • 17
  • 28
  • 2
    Indeed, one of our solutions was eventually using `https`. We just didn't want to pay for certificate for debugging env. – Gil Epshtain Nov 13 '22 at 09:31
  • 1
    This solution is the only one that worked for me after hours and hours of searching. Thank you very much. – DINO Dec 05 '22 at 21:36
  • Not much relevant here but if anybody is using Create React App for a local app. Use https://create-react-app.dev/docs/using-https-in-development/ That solved my issue. – Avtar Nanrey Apr 29 '23 at 17:36
3

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
Gil Epshtain
  • 8,670
  • 7
  • 63
  • 89
  • If you don't want to uninstall your current Chrome you can use Chromium dev build from cypress: https://chromium.cypress.io/mac/beta/90.0.4430.40. Also, thanks to that you can skip this "Prevent auto-update" step – Gnato Mar 10 '22 at 13:38
3

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.

enter image description here

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

enter image description here

I hope this brightens your day

  • 3
    As I already mentioned in a different answer that provides the same solution - this will not work! In the 'Application' tab you'll only see cookies that were successfully set. But in my case, the cookie failed to set, so it doesn't appear on that list – Gil Epshtain Jul 05 '21 at 09:14
  • Sorry, but the solution is oriented so that third-party cookies can be consumed by other sites (for example localhost), that's what the Samesite attribute is based on. To set the development cookie on localhost, you must access the development environment in a browser tab and if the cookie is present, apply the modifications Samesite = None Secure-> check so that it can be consumed from the localhost tab – Reynier Ramos Portieles Jul 06 '21 at 11:57
1

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.

joelac32
  • 11
  • 3
0

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" />
...
Sahi Repswal
  • 190
  • 3
  • 12
-1

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).

  • How to set cookie attribute in dev-tools? – Gil Epshtain Jun 08 '21 at 11:35
  • In the 'Application' tab, go to 'Cookies' on the left hand side. Then you'll see all the cookies for the current site, select the site and double click the cookie entry you want to change in the list. For stackoverflow it's like this: Application -> Cookies -> ...stackoverflow....-> then there's a list of 5 cookies, double click on the SameSite entry of the last one, type 'None' - Done. – Guest123 Jun 09 '21 at 08:30
  • 4
    Unfortunately, this will not work. In the 'Application' tab you'll only see cookies that were successfully set. But in my case, the cookie failed to set, so it doesn't appear on that list – Gil Epshtain Jun 09 '21 at 08:59