Cloudflare's Free Plan Now Edits Your HTML by Default

A developer moved their nameservers to Cloudflare to serve files from an R2 bucket. Their site was deliberately JavaScript-free — plain HTML, nothing else. A while later they noticed every page was loading beacon.min.js from static.cloudflareinsights.com. They hadn't added it. Cloudflare had, at the edge, on the way to the browser. The resulting Hacker News thread filled up with people discovering the same script on their own sites, and with the same question: since when does my CDN edit my HTML without asking?

Since October 15, 2025, is the answer. Cloudflare announced that Web Analytics — its real user monitoring product — would be switched on by default for every free-plan zone. Existing zones got a window to opt out ahead of the flip; anything onboarded after that date starts life with RUM enabled. If your DNS records are proxied (orange-cloud), Cloudflare rewrites your HTML responses in flight to append the beacon script. Pro, Business, and Enterprise plans weren't auto-enrolled, mostly because they already get server-side analytics from edge logs and don't need client-side collection to see traffic.

The surprise factor is what makes this a story. Nobody in that HN thread was reading Cloudflare's blog the week the default changed. They found out months later, usually via a console error — content blockers and Firefox's tracking protection block cloudflareinsights.com, so the injected script announces itself as a failed request on sites whose owners thought they shipped zero JavaScript.

Cloudflare has always rewritten HTML — but never like this

Modifying response bodies at the edge isn't new for Cloudflare. Rocket Loader rewrites your script tags. Email obfuscation injects a decoder script. But those were features you turned on, and the mental model held: proxied traffic passes through a transformer, and you control the transformations. Web Analytics itself followed that model for five years — it launched in late 2020 as an opt-in, privacy-first alternative to Google Analytics, and it was genuinely a good citizen: no cookies, no localStorage, no fingerprinting, aggregate Core Web Vitals instead of user tracking.

The product didn't get worse in October. The consent model did. "We inject JavaScript into your pages unless you find the toggle" is a different contract from "we'll inject it if you ask," even when the JavaScript is benign. And Cloudflare's own rollout betrays awareness of the problem: EU and UK visitor traffic is excluded from collection by default. If auto-injecting a telemetry beacon were as unambiguously harmless as the announcement's framing suggests, there'd be no reason to carve out the jurisdictions with functioning consent law.

There's a useful precedent for how this should have gone. When the Go team proposed opt-out toolchain telemetry in 2023, the backlash was loud enough that they shipped it opt-in — and still got useful data. And Go's telemetry only instrumented the developer's own machine. Cloudflare's default is a step beyond: you're not being opted into sending your data, you're being opted into serving a third-party script to your visitors. The consent you're presumed to have given is on behalf of other people.

What this means for your zones

Concretely, you're affected if all three are true: free plan, proxied records, and you haven't explicitly disabled RUM. Checking takes ten seconds:

curl -s https://yoursite.example/ | grep -i cloudflareinsights

If that returns a script tag you didn't write, go to Analytics & Logs → Web Analytics in the account dashboard, find the auto-created entry for your hostname, and disable it — or do it properly via the API by setting auto_install: false on the RUM configuration, which you can script across every zone in a large account. Do the audit even if you think you'd have noticed; the burned parties in the HN thread include people who watch their sites closely.

A few sharper edges worth knowing:

• Strict CSP blocks the beacon, and Cloudflare's docs answer is to add static.cloudflareinsights.com to your script-src. Don't. If you didn't ask for the script, the correct fix is disabling the injection, not widening your policy to accommodate it.
• DNS-only (grey-cloud) records are untouched, because injection requires Cloudflare to terminate and rewrite your HTTP responses. If you only came for DNS or for R2 custom domains, grey-cloud everything that doesn't need the proxy.
• Cloudflare Pages has its own injection path, and community threads report the beacon appearing on Pages sites even with Web Analytics disabled at the account level. If you're on Pages, verify with curl rather than trusting the dashboard state.

The trap that caught the original poster is worth naming, because it's structural: more and more of Cloudflare's platform — R2 custom domains, Workers routes, Pages — requires your zone to be on Cloudflare with proxying enabled. Each of those products is a reason to orange-cloud a domain, and orange-cloud is now the tripwire for default HTML modification. You come for object storage; you leave serving telemetry.

The real cost is the mental model

Here's the editorial call: Cloudflare Web Analytics remains one of the more privacy-respecting analytics products on the market, and if you were going to add analytics anyway, enabling it deliberately is a fine choice. The auto-injection default is still a mistake — not because of what this script does, but because of what it normalizes.

A reverse proxy fronting roughly a fifth of the web just moved "we modify your response bodies" from opt-in feature to background behavior. That breaks the assumption that the bytes your origin serves are the bytes users receive — the assumption underlying HTML integrity checking, reproducible deploys, and every security review that audits what's in the repo rather than what's on the wire. Once operators accept silent injection for analytics, the next injected default has precedent, and each one gets a smaller blog post.

The fix costs Cloudflare almost nothing: a checkbox at zone onboarding, default off, one sentence explaining the value. They'd get less data and keep more trust. For now, the practical takeaway fits in one line — if you orange-cloud a domain on the free plan, you're a publisher of Cloudflare's JavaScript until you say otherwise. Audit your zones accordingly.