This makes the client only load self-hosted scripts, or scripts only from the specified origins, among the other directives CSP allows (e.g. restricting styles, images, frames, etc.): https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
If Cloudflare (CF) has r/w access to the response body, which CF does have by default, then CF can easily modify or remove that <meta> tag
Third parties injecting scripts, content, etc. into response bodies (web pages) is usually cited as a rationale for using HTTPS^1
CF somehow avoids the usual objections. CF is a MiTM but few people object
1. For example, an advertising company that releases a web browser may not want an ISP to inject scripts, etc. into web pages as it might compete with the advertising company. It might market use of HTTPS in its browser to developers at conferences, etc. as a defence against such ISPs
Yup, I explicitly had all anaytics turned off. But had a few sites using Cloudflare for caching. Now I'm checking and seeing this on all of them. This is gross and unacceptable. "Caching" does not mean "modifying my site".
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?
I just went and switched them to DNS only, they were on Proxy by default, that also should have been opt-in. Maybe I missed the option while switching the nameservers because I did it in a hurry but still.
I agree it is a bit confusing, but it makes sense if you think about the expected default use case, which is enabling the cloudflare CDN for customers. They expect people to be using their CDN.
I use them for my registrar, because they offer domains at cost and you can’t beat that. But yes, they make it an extra step to use them without using the CDN.
Once you figure it out, it is fairly straightforward, though, and you can’t beat the price.
A simple screen when I did the switch that requires explicitly ‘Enable Proxy’ or ‘skip for now’ would have been enough. Also for ‘Enable Analytics’. None of these existed, or not very obvious otherwise I’d seen them.
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?
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).
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.
When you set up CNAME and certain other records in Cloudflare DNS, it defaults to (and heavily discourages you to disable) "proxied" records, which I believe means that the record points to a Cloudflare-owned host which then acts as a reverse proxy to whatever value you'd set. So from the console it looks like you've set the CNAME to a certain value, but in practice it'll be set to a different thing and transparently forward everything via Cloudflare. This is probably where the analytics get inserted, alongside a bunch of other Cloudflare features.
You can disable this, at which point the record will be set as a normal DNS record.
I can see the advantage of Cloudflare's proxy systems, but I wish they'd be clearer about when they're being used and not pretend that this is some DNS feature or that records have been set to one thing when they've actually been set to something else. If nothing else, it makes debugging DNS issues a lot more confusing, particularly if you're not a DNS expert.
>I can see the advantage of Cloudflare's proxy systems, but I wish they'd be clearer about when they're being used and not pretend that this is some DNS feature or that records have been set to one thing when they've actually been set to something else. If nothing else, it makes debugging DNS issues a lot more confusing, particularly if you're not a DNS expert.
You could say the same about the reverse, ie. people set up their site on cloudflare, thought it was "protected", but really it's dns only and their servers are wide open. It's even worse if they migrated from another provider that was providing ddos protection.
Yes, the person who controls the DNS controls the certificate.
What a certificate is supposed to verify is that traffic is going to the right place. If you designate cloudflare as the rightful host of your website then they can get a certificate.
This isn't an edge case though. This is cloudflare's primary product. It is why users use them.
They have a product called Magic Transit that offers DDoS protection and such for plain IP traffic, where Cloudflare does not terminate TLS. Pricing is not public but starts in the five-digit USD per month range according to people I talk to.
This may tell you something about how keen Cloudflare are to handle traffic they themselves cannot decrypt.
I can’t recall if there was a setting to enable reverse proxy, if there was it was On by default since I didn’t expect to have reverse proxy enabled as well. But you can also rp without injecting a script. That’s overdoing it.
I don't know what happened in this situation but beware that CF and similar providers are not true DNS hosting providers. They do DNS, but only so their CDN stuff works, and to lock their customers from using whatever DNS hosting they want. Various things that one might reasonably want to do with your DNS zone are not possible with their product. So use it only because you need to do so in conjunction with their core services.
TLS terminates at Cloudflare, not at your origin. When a record is proxied (the orange cloud), CF holds the certificate the browser validates against and opens a separate connection to your server, so it sees plaintext on both sides and can rewrite the HTML on the way out. Same mechanism that makes the WAF and caching work, so it isn't specific to the analytics feature.
Worth checking which of your records are actually proxied. DNS-only ones (grey cloud) pass straight through and can't be touched.
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.
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?
Cloudflare is doing this already. Once they had enough monopoly power, they started a program to block all bots that don't undergo invasive KYC procedures. Eventually, they might become a KYC broker for regular browser users too. The free internet is over.
A public service reminder to anyone setting up their domains that there are many alternatives to Cloudflare, like EG Bunny.net (I am not affiliated, just a happy customer) and that by using one of these other DNS providers, you
- play your small part in keeping the Internet open
- delay or avoid entirely the enshittification that is 100% foreseeable when buying the "free" services of a quasi-monopoly vendor.
If you're not an enterprise customer, alternate providers will also give you every single feature you could ever need and more, and fewer surprises like the OP's.
Oh gosh I didn’t enable anything like that also. I just wanted the nameservers in order to serve the bucket under my subdomain. What else is there I wonder?
The main reason anyone chooses cloudflare is for their CDN (which I suppose is a "reverse proxy"...not a way I'd refer to it but technically yes that's essentially what it's doing). If you don't need the CDN or any of the other fancy features there are plenty of straight DNS providers out there (and often provided by the registar these days).
OK, how can Cloudfare edit your HTML without it passing through your server?
If the browser connects directly to your web server, how can there be Cloudfare's analytics stuff?
Check what IP address you are connecting to when you load textlog.cc. Is that an address that you control? If it's not an address that you control, where is it getting your page, and is that not called proxying?
"can't" is incorrect. As your name server, they can decide to turn the reverse proxy/caching at any point in the future, write an obscure blog post about how this is the best solution for all (a post that gets 2 comments on HN due to other news that week), and you'd only find out about it 11 months later in a thread like this one.
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
This makes the client only load self-hosted scripts, or scripts only from the specified origins, among the other directives CSP allows (e.g. restricting styles, images, frames, etc.): https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
Third parties injecting scripts, content, etc. into response bodies (web pages) is usually cited as a rationale for using HTTPS^1
CF somehow avoids the usual objections. CF is a MiTM but few people object
1. For example, an advertising company that releases a web browser may not want an ISP to inject scripts, etc. into web pages as it might compete with the advertising company. It might market use of HTTPS in its browser to developers at conferences, etc. as a defence against such ISPs
The RUM Diaries: Enabling Web Analytics by Default
(2 points, 11 months ago): https://news.ycombinator.com/item?id=45291323
(1 point, 11 months ago): https://news.ycombinator.com/item?id=45339321
<script type="module" src="https://static.cloudflareinsights.com/beacon.min.js/v4513226..." integrity="sha512-ZE9pZaUXND66v380QUtch/5sE9tPFh2zg45pR2PB0CVkCtOREv2AJKkSidISWkysEuQ0EH8faUU5du78bx87UQ==" data-cf-beacon='{"version":"2024.11.0","token":"c0859b51a7804ab5a9cc8e9e2b2c4cde","r":1}' crossorigin="anonymous"></script>
You must be allowing Cloudfare to terminate your HTTPS connections; i.e. using them for actual proxying.
I have all my domains set to DNS only, so no CF proxy. Wondering if that is why?
I use them for my registrar, because they offer domains at cost and you can’t beat that. But yes, they make it an extra step to use them without using the CDN.
Once you figure it out, it is fairly straightforward, though, and you can’t beat the price.
The proxy is like 99% of why people use Cloudflare
https://limereader.com/
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?
It seems incredibly unlikely cloudflare does this when just DNS hosting, if for no other reason then that this would break so many things.
You can disable this, at which point the record will be set as a normal DNS record.
I can see the advantage of Cloudflare's proxy systems, but I wish they'd be clearer about when they're being used and not pretend that this is some DNS feature or that records have been set to one thing when they've actually been set to something else. If nothing else, it makes debugging DNS issues a lot more confusing, particularly if you're not a DNS expert.
I think a better question is: why would you be using cloudflare, if you didn't want that?
You could say the same about the reverse, ie. people set up their site on cloudflare, thought it was "protected", but really it's dns only and their servers are wide open. It's even worse if they migrated from another provider that was providing ddos protection.
Or is it that when you sign over DNS to a provider, they can take over your cert? They can "ass-cert" their own? :)
What a certificate is supposed to verify is that traffic is going to the right place. If you designate cloudflare as the rightful host of your website then they can get a certificate.
This isn't an edge case though. This is cloudflare's primary product. It is why users use them.
This may tell you something about how keen Cloudflare are to handle traffic they themselves cannot decrypt.
Worth checking which of your records are actually proxied. DNS-only ones (grey cloud) pass straight through and can't be touched.
Make a CNAME record the same way you would for a CDN subdomain.
(I am not yet running this in production, YMMV.)
[1] - https://www.youtube.com/watch?v=a3Xxi0b9trY
And they can fuck off.
- play your small part in keeping the Internet open
- delay or avoid entirely the enshittification that is 100% foreseeable when buying the "free" services of a quasi-monopoly vendor.
If you're not an enterprise customer, alternate providers will also give you every single feature you could ever need and more, and fewer surprises like the OP's.
If they can inject script, they can also snoop on all your cleartext traffic without you knowing....
If the browser connects directly to your web server, how can there be Cloudfare's analytics stuff?
Check what IP address you are connecting to when you load textlog.cc. Is that an address that you control? If it's not an address that you control, where is it getting your page, and is that not called proxying?