Tell HN: Cloudflare silently injects its analytics when you switch nameservers

591 points by stagas ↗ HN
A few hours ago I switched my nameservers to Cloudflare in order to enable R2 bucket serving through my own subdomain, and I found out that it silently had injected a JS analytics snippet in my HTML-only JS-free site textlog.cc — I had to go to the Analytics dashboard, Add the site to the analytics and then disable the snippet. I find this approach entirely invasive, you should opt-in to features like that not have to opt-out. Just a warning out there to folks who might not be aware of this.

66 comments

[ 0.26 ms ] story [ 17.7 ms ] thread
To add to your experience: It was also very hard, for me, to find the setting that disables this JavaScript.
Isn't this well known when using CF as a proxy? Not sure how they would provide traffic / DDoS telemetry otherwise.
Yes, they add the js if "web analytics" is enabled. I believe I had to manually enable it on my old sites though. Maybe it's enabled by default when adding new domains?
(comment deleted)
Surprise! The man in the middle man-in-the-middles! This is only the beginning, when you’ll get used to this they’ll do worse and worse, enshittification, remember?
I'm curious which governments have spies within CloudFlare.
Took me a minute to realise this isn't 1.1.1.1 (which Cloudflare also runs), but their original website DNS hosting service.
You left out the part about how you use them as a reverse proxy, which is decoupled from DNS. One is coincidental; the other required.

If they can inject script, they can also snoop on all your cleartext traffic without you knowing....

Why would they snoop your traffic?

Ah, because they can.

yep, last website I did was JS free 100% except that pesky cloudflare script
Is there an opt-out mechanism at least? CF is burning goodwill in months it built over the last decade.
If you navigate to the domain itself, then to Analytics > Web Analytics there's a Quick Action for the RUM Settings.
(comment deleted)
Noticed this the other day as well. Sketchy as fuck. I didn't have analytics enabled. I had to go and enable to get access to the option to turn this off
Are you using CF as a proxy or only for DNS? I ask because I just went to check my domains on the dashboard (some purchased a few years ago, one purchased just a couple days ago), and none of them have Web Analytics enabled.

I have all my domains set to DNS only, so no CF proxy. Wondering if that is why?

> injected a JS analytics snippet in my HTML-only JS-free site textlog.cc

Cloudflare injected hostile code into a site they are not even hosting? If it's HTTPS, how do they even do that?

Does it violate the "exceeds authorized access" provision in the Computer Fraud and Abuse Act?

We use Cloudflare tunnels for connecting distributed workers to central infrastructure. Haven't seen this on tunnel traffic, but good to know it happens on nameserver-managed sites. Another reason to audit what your CDN injects — same applies to checking your security headers regularly.
It's not necessary to use Cloudflare hosted DNS to use R2 with a custom subdomain.

Make a CNAME record the same way you would for a CDN subdomain.

(I am not yet running this in production, YMMV.)

Thank you for this. I indeed had it up on mine. Cloudflare has switched defaults a couple times now, which honestly is wild to me.
Spies. Spies everywhere
(comment deleted)
If you're only using Cloudfare for DNS, but HTTPS connections go directly to your server, how does it inject HTML?

You must be allowing Cloudfare to terminate your HTTPS connections; i.e. using them for actual proxying.

The OP doesn't understand what they are configuring they have Cloudflare setup as a proxy.
I noticed the same thing with email-decode.min.js on my site. It turns out it's the "Email Address Obfuscation" feature, which I didn't expect to be on by default.
This reminds me of the old free hosts that would inject their own scripts/ads on pages hosted by them, but their implementation would do it only after detecting the closing HTML tag (either </body> or </html>, can't remember) and the various tricks to get around it, including omitting the tag (browsers don't care), rAnDoM case tags (some were hardcoding lower or upper and comparing case-sensitively), and messing with the content type and relying on the browser to detect correctly since it didn't inject into other types (not sure how the current browsers will handle that).