Is this in a new browser / in incognito? I believe existing browser cookies might remain without samesite being set.
@Judge it was tested using the following conditions:
- The same browser.
- The same browser with static content caching disabled.
- The same browser with static content caching disabled, cookies removed, logged in and out.
And this procedure was repeated more than 3 times. - Incognito mode.
In all cases result was the same:
A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.
Developer Tools mode shows “SameSite=Lax”.
Researching for details…
So the warning looks like it’s for one of your own server’s cookies, not __cfduid.
@Judge that not seem to be true.
The one internal cookie is only for youtrack.itsvit.org and it doesn’t have “SameSite=Lax” attribute.
But __cfduid has “SameSite=Lax” and uses .itsvit.org domain.
Which according to the following document means that there were no SameSite attribute specified for __cfduid cookie by Cloudflare
https://www.chromestatus.com/feature/5088147346030592
__cfduid did set SameSite attribute by setting it to Lax, which is why you can see it in your screenshot
The other cookie there, set by YouTrack, does not have a samesite attribute, so Chrome is complaining about that one.
It doesn’t look like Jetbrain’s issue tracker has an issue for that, although I imagine it’s on their radar.
1 Like
@Judge Cookie for youtrack.itsvit.org doesn’t seem to be cross-site cookie.
When __cfduid seem to be the one cross-site cookie.
Because there are only 2 cookies.
A cookie associated with a cross-site resource at was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at and .
You’re right, I just went to the website and actually didn’t get the warning at all
I see you’re logged in on that page, so maybe some deeper internal cross-site request is what triggers that notice, so maybe that’s it, but I don’t see any other cookies on your first image. Regardless, the __cfduid cookie on your side does have SameSite set (to Lax) so I don’t see why it would be the CF cookie.
1 Like
Thanks, @Judge!
Will continue the investigation and ask clarification from JetBrains.
Hi,
The SameSite=Lax is OK if the site is on top of browser. But if the site is inside an iframe on different domain SameSite=Lax is a problem because the domain on iframe is considered a third party domain - so, browsers will block these cookies. Look the image below:
- This sample is running on Chrome 80.0.3987.42 beta 64 bits
- On top of browser we have one domain “.consciencia.com.br” (without Cloudflare)
- The Developer Tools is showing the iframe request-response on other domain “.veloxtix.com” (on CloudFlare)
- Cloudflare cookies are blocked (__cfduid and __cflb)
- These cookies should be SameSite=None and secure to work on this scenario.
My question is: Cloudflare will support this scenario?
I beleave others sites will have problem with it.
Thanks,
@Judge @cloonan
itsvit.hurma.work doesn’t use any iframe or any other reference to any of https://support.cloudflare.com/, http://dash.cloudflare.com/, http://cloudflare.com/.
And here is the same page loaded without Cloudflare.
This makes me think that Cloudflare cookies are reason why Chrome is complaining.
I appreciate if you could let me know is it going to be fixed by Cloudflare?
And how soon?
I’d like to make sure it is fixed before it is deprecated in Chrome.
I don’t want to find myself urgently switching off Cloudflare one day if it affects user experience negatively.
Ah I see, these are Cloudflare cookies for support.cloudflare.com, dash.cloudflare.com, and the root CF domain. This warning will only show for you if you/your visitors have already visited Cloudflare’s websites themselves, which is unlikely. Even when proxied by CF, an incognito session shows no cookie warning (since it doesn’t have the non-updated cookies for support, dash, and the root.
Also, these only show up since you use cdnjs. CF is not making any cross-origin requests to its own domains.
1 Like
Hi, I’m getting some warnings about the __cfduid as well.
Example:
When I go to mysitecom, the page loads resources (scripts, images, etc) from mysitecdncom.
The __cfduid cookie is set with the domain mysitecdn.com and samesite is set to “Lax”. This means that Chrome blocks the cookie from being sent on subsequent requests for resources.
So far, on my end, everything appears to be loading correctly. Does it matter that the cookie is being blocked? Am I missing something, is this a scenario that you currently support or plan to support?
No it does not. Chrome will only show this warning when a cookie does not have the SameSite attribute, but the __cfduid cookie does have that. In general you don’t need to worry about Cloudflare’s cookies.
The exception to “you won’t get this message for Cloudflare cookies” is when you personally have visited cloudflare’s website/dashboard, this community site, or the support site and your website loads resources from cdnjs. In that case, the warnings won’t show up for your website’s visitors, and you can test this in an incognito session/private browsing session.
1 Like
Hmm, I still seem to be misunderstanding or misinterpreting what I’m seeing. Here’s what I’m seeing:
Browser (Chrome Canary 81) makes requests and I filter the network traffic to see requests that “Has blocked cookies”
I inspect the request made for base.js. It’s coming from a server that is identifying itself as a “cloudflare” server. I take a note of the __cfduid cookie that I receive from the server.
(see second post…because new users can only put one image per post)
I open up the cookie inspector in the dev tools and filter by “Only blocked”. I verify that the value of the blocked __cfduid cookie is the same as the cookie I received from the server.
(see third post…because new users can only put one image per post)
To me, it seems like the cookie is being blocked. To clarify, when I say “cookie is being blocked”, I mean that my web browser refuses to send the cookie back to the originating server on subsequent requests.
Based on what I know about the upcoming Chrome update, this is the correct behavior in this particular situation. However, are there any issues with my browser not sending the __cfduid cookie back to the server when making multiple requests.
Hopefully that all makes sense. Thanks for your patience and help!
Will Cloudflare support iframe on different domain scenario? On this scenario, these cookies should be SameSite=None and secure. Cookies with SameSite=Lax are blocked because the iframe domain is different from top domain and all cookies from iframe domain are considered as third party (see my post above showing it).
Thanks,
1 Like
Seconding this question right here since we’re trying to work out the same case: An iframe of a certain domain (managed by Cloudflare) being inserted in a site with a different domain.
Requests setting the __cfduid cookie are doing so in SameSite=Lax mode, which triggers a warning in Chrome’s dev console. As far as I understand (correct me if I’m wrong), SameSite should be None - at least in this specific case. Is this something you guys are working on or have any recommendations for?
I’m not fully aware of the implications that a blocked __cfduid cookie would have, if any, but it would also be nice to work this out even if just not to trigger unnecessary warnings in the console.
Ditto on @gabriel.rc comments.
We have an iframe from one domain (managed by cloudflare) being embedded into a different domain. We are seeing the same issue where _cfduid is being set to SameSite=Lax.
"This set-cookie didn’t specify a “SameSite” attribute and was defaulted to “SameSite=Lax” and broke the same rules specified in the SameSiteLax value."
Will this be fixed by Cloudflare? If not, what are the implications that a blocked _cfduid cookie would have?