A Hacker News post by developer stagas just exposed something most Cloudflare users don't know: when you switch your nameservers to Cloudflare, the company silently injects a JavaScript analytics snippet into your website's HTML — without asking, without notifying you, and without any opt-in.
The post, which hit 468 points and 121 comments in 14 hours, describes a jarring discovery:
"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."
The developer's site was intentionally JavaScript-free. Cloudflare injected analytics code into it anyway. And the only way to remove it was to navigate through the Analytics dashboard — a setting most users would never think to check.
What Cloudflare Is Actually Doing
When you point your domain's nameservers to Cloudflare, Cloudflare becomes a reverse proxy for your traffic. All requests to your domain pass through Cloudflare's servers before reaching your origin server. This architecture gives Cloudflare read-write access to your HTTP response bodies — meaning they can modify the HTML, CSS, and JavaScript that your visitors receive.
In this case, Cloudflare uses that access to inject a JavaScript analytics tracking snippet into your pages. The snippet feeds data to Cloudflare's Web Analytics dashboard, showing you traffic stats, visitor geography, and page performance metrics.
The problem isn't that Cloudflare offers analytics. The problem is the default: it's opt-out, not opt-in. You have to discover it's there, navigate to the right dashboard, and manually disable it.
Why This Matters
It violates the principle of least surprise. When you switch nameservers to Cloudflare, you expect DNS routing and CDN services. You don't expect your HTML to be modified. You certainly don't expect JavaScript to be injected into a site you deliberately built without it.
It's a privacy concern for your visitors. The injected analytics script tracks your visitors — their IPs, browsing patterns, and behavior — and sends that data to Cloudflare. If you've built a privacy-focused site, Cloudflare's injection silently undermines that commitment without your knowledge.
It breaks trust in the proxy model. Cloudflare's entire value proposition is built on being a trusted intermediary. When that intermediary silently modifies your content, it raises a fundamental question: what else might they inject? What else might they modify? The same architecture that enables analytics injection could theoretically be used for advertising, A/B testing, or anything else Cloudflare decides to add to the default stack.
It's especially problematic for static sites. Many developers use Cloudflare with static site generators specifically to avoid JavaScript bloat and tracking. Cloudflare's injection silently reintroduces both.
How to Stop It
Method 1: Disable Web Analytics in Cloudflare Dashboard
- Log in to your Cloudflare dashboard
- Navigate to Analytics & Logs → Web Analytics
- Add your site if it isn't already listed
- Find the Settings for your site
- Disable the JavaScript beacon option
This removes the injected snippet, but you have to know it's there first.
Method 2: Use Content-Security-Policy (CSP)
As commenter okzgn pointed out in the HN discussion, you can use a Content-Security-Policy header to restrict which scripts can execute on your site:
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
This tells the browser to only execute scripts hosted on your own domain. Cloudflare's injected analytics script, served from a different origin, would be blocked by this policy.
However, as another commenter noted, since Cloudflare has read-write access to your response body, they could theoretically modify or remove your CSP meta tag before it reaches the visitor. A more robust approach is to set CSP as an HTTP response header at your origin server, which is harder (though not impossible) for Cloudflare to strip.
Method 3: Disable Cloudflare Proxy (DNS Only)
If you don't need Cloudflare's CDN and proxy features, set your DNS records to DNS Only mode (grey cloud icon instead of orange). This routes traffic directly to your server without passing through Cloudflare's proxy, eliminating the possibility of HTML modification.
You lose the CDN, DDoS protection, and other proxy features, but your HTML remains untouched.
Method 4: Use Cloudflare's API to Disable Analytics
If you manage multiple sites, you can use the Cloudflare API to check and disable analytics across all your zones programmatically:
# List all zones
curl -X GET "https://api.cloudflare.com/client/v4/zones" \
-H "Authorization: Bearer YOUR_API_TOKEN"
# Disable analytics for a specific zone
curl -X PUT "https://api.cloudflare.com/client/v4/zones/ZONE_ID/settings/web_analytics" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"enabled": false}'
The Bigger Picture: Your CDN Is a Man-in-the-Middle
The Cloudflare analytics injection is a reminder of something we often forget: any CDN or reverse proxy that terminates TLS on its end is a man-in-the-middle by design. It has the technical ability to read and modify everything that passes through it.
This isn't unique to Cloudflare. Any CDN with proxy capability — AWS CloudFront, Fastly, Akamai — can theoretically modify response bodies. The difference is in defaults and transparency. Cloudflare's choice to make analytics injection opt-out rather than opt-in is a business decision, not a technical necessity.
As one HN commenter put it: "Letting Cloudflare operate DNS and direct traffic through its proxies gives Cloudflare control. It's interesting to see how they use it under market pressures."
What This Means for Developers
Audit your Cloudflare settings regularly. Cloudflare adds features frequently, and not all of them are opt-in. Check your dashboard after any configuration change.
Use CSP headers as a defense-in-depth measure. Even if you trust your CDN today, a CSP header protects you against unwanted script injections — from your CDN or from anyone else who might compromise the chain.
Consider DNS-only mode for sites that don't need proxy features. If you're using Cloudflare primarily for DNS, the proxy isn't necessary and introduces unnecessary risk of content modification.
Read the HN thread for more community solutions. The discussion at https://news.ycombinator.com/item?id=49322107 includes technical approaches from developers who've dealt with this issue.
Conclusion
Cloudflare provides genuinely valuable services — CDN, DDoS protection, DNS, edge computing. But their default-on approach to analytics injection represents a troubling pattern: modifying user content without explicit consent and requiring users to discover and opt out of changes they never agreed to.
The fix is simple once you know it exists. The problem is that most users don't know. Posts like this one on Hacker News are how they find out.
