Google Chrome warning about Cloudflare cookie

Chrome itself solves the issue. Read this again. Cloudflare will fix this before it will become an issue, for sure. I don’t feel the need for being so overly dramatic over something that is in the not near future.

2 Likes

@matteo You are wrong, but I won’t waste my time arguing with you, simply because I don’t recall asking for your judgment, which I now have zero trust in following.

Well, that escalated quickly. Please, do as you wish.

Maybe a noob question… but why would you want to a cookie to set a HTTP header flag with HTTPOnly? Isn’t it best to always use HTTPS?

@getinthere007 This isn’t the topic of this thread. We are fully HTTPS already

Think noone will care about :man_shrugging:

1 Like

@getinthere007 An HttpOnly cookie just means it’s accessible server-side only (not via JavaScript), irrespective of HTTPS vs. HTTP. A Secure cookie means HTTPS. HttpOnly should’ve been named ServerSideOnly or something.

@matteo The issue already affects developers, and it becomes a production issue with Chrome Beta users in a few days as I pointed out here.

Cloudflare needs SameSite=None on its cookies ASAP.

2 Likes

Yeah, missed that post. One question I have, but I may be missing something myself is: from the console error Chrome throws it seems like they simply won’t set the cookies, why wouldn’t the resources not load? :thinking:

The resources still load. I tried turning cookies off completely and this didn’t have any effect.

This is what this cookie does:

The _cfduid cookie helps Cloudflare detect malicious visitors to our Customers’ websites and minimizes blocking legitimate users. It may be placed on the devices of our customers’ End Users to identify individual clients behind a shared IP address and apply security settings on a per-client basis. It is necessary for supporting Cloudflare’s security features.

Cloudflare places the _cfduid cookie in an End User’s web browser after the user has met certain security requirements, such as solving a Captcha challenge. The cookie is a session cookie that expires after 30 days.

Enterprise customers may request to disable the _cfduid cookie by contacting Cloudflare Support, but Cloudflare’s ability to detect and mitigate the impact of malicious visitors to a Customer’s website will be significantly impacted.

https://support.cloudflare.com/hc/en-us/articles/200170156-Understanding-the-Cloudflare-Cookies

From the end users point of view I believe the issue will arise to those who are presented with a challenge (e.g they are behind a shared IP from which some malicious activity was detected). Without the cookie Cloudflare might be challenging (or blocking) them on every request. This is hard to test because I am almost never presented with such challenges by Cloudflare. However people from certain regions of the world might get challenged quite often.

Another issue in our case is the actual warning (which I guess will became an error when this change takes effect), since developers who use our embeds do not like seeing warnings and errors in their console.

One last thing: I read that some older versions of MacOS and iOS do not understand “SameSite=None” and they interpret is as “SameSite=Strict”, which has the opposite effect.

Yeah, that was my understanding. Only challenges are an issue I guess.

To test it simply force a challenge on a specific URL and go to it. It can be easily done with a Firewall Rule.

Wouldn’t that always show the challenge regardless of the cookie?

Not really, that would challenge you once every x amount of time, which you can set in your Dashboard.

Even then I am not sure if this will prove anything since my IP is not a suspect one and I am the only one using it. They say that the cookie is used “to identify individual clients behind a shared IP address”

They don’t know that you are the only one though. They would behave as if you weren’t.

@cloonan Is Cloudflare aware that Cloudflare’s important cookies begin failing today with the release of Chrome Beta 79? Is work on the fix assigned to anyone internally? I posted about this here a week ago.

This impacts sites that request content from Cloudflare’s CDN/Stream/Workers on another domain. It’s scary* that Cloudflare is behind the curve on this one.

*Happy Halloween from our engineers to yours. :ghost: We appreciate you working on this issue.

1 Like

To everyone in this thread (which I started):

This is a very real problem (as @bertap and I have said multiple times), and Cloudflare’s support is now telling me that they are actively working on solving it.

I will update this thread when they update me further.

2 Likes

Thank you @david33 for being one of the few people in this thread that recognizes the problem instead of trying to pointless defense. Look forward to your updates.

1 Like

I have the same issue at ([http://www.makhtutat.com](http://my site)). I’m only using JS and DataTables app. The remaining site is html and css. I only want to see this issue solved. Also to keep this thread alive since there is the warning at the end of this page “This topic will close 3 days after the last reply.”!!!

1 Like

To everyone: after making the effort to start this thread and pointing out a very real issue which still hasn’t been resolved, I just got flagged as “inappropriate” by someone anonymously. This is unbelievable. This someone in question, please come forth and have the integrity of revealing yourself.

We are paying customers, for heaven’s sake.

My pleasure. I flagged the response in question. It was rude and uncalled for and I would like to ask you to stick to a civilised tone. Thank you.