What Cloudflare Injects Into Your HTML

A nameserver switch quietly turns on response rewriting. One curl command shows every script Cloudflare added to your pages.

Dafallah Ibrahim

— 2 min read
Share

Repointing your nameservers to Cloudflare feels like a pure DNS move. According to a 304-point thread on Hacker News this morning, it can also start injecting an analytics beacon into every HTML response you serve. Your site is now shipping code nobody on your team wrote, reviewed, or deployed.

The uncomfortable part: this isn't a bug or a breach. It's what happens the moment your traffic becomes proxied.

Why this matters

When you add a zone, Cloudflare imports your DNS records with proxying enabled by default — the orange cloud. A proxied record means Cloudflare terminates the connection and can rewrite response bodies at the edge. DNS-only records pass through untouched, but most people never flip that toggle.

Serving bytes you didn't ship matters for three reasons: you may be collecting visitor data without consent you never gave, your performance budget now includes scripts outside your bundle, and your CSP and debugging assumptions break in confusing ways.

How it works

Several Cloudflare features are response rewriters in disguise. Web Analytics has an automatic setup mode that injects its beacon server-side — no snippet pasted into your template required. Rocket Loader rewrites and defers your script tags. Email obfuscation swaps mailto links and adds a decoder. Zaraz injects a whole tag manager.

Because the injection happens on the wire, it's invisible to your repo, your CI, and your code review. And since the scripts load from same-origin paths like /cdn-cgi/rum/, your CSP usually won't flag them either.

Here's the part that makes auditing easy: it's server-side rewriting, not browser magic. A plain curl sees exactly what a browser sees.

Where this helps

  • Post-migration audits — run it across apex, www, and app hosts before you assume the migration was "just DNS".
  • CI gates — a deploy check that fails if unexpected /cdn-cgi/ artifacts appear in responses.
  • Consent reviews — an analytics beacon you never opted into is a real GDPR/ePrivacy problem, not a theoretical one.
  • Mystery debugging — CSP violations or odd script ordering that started "randomly" after the nameserver switch.

Watch out

Only proxied traffic gets rewritten. Flipping a record to DNS-only is the instant kill switch, but you lose the CDN and WAF too. To keep the proxy and drop the beacon, disable automatic setup on the Web Analytics settings page — other injectors live under Speed → Optimization and Scrape Shield.

Edge-cached HTML can keep serving the old rewritten copy after you change settings, so purge the cache before re-testing. And subdomains are separate records — audit each host, not just the apex.

Try it yourself

for host in example.com www.example.com app.example.com; do
  printf '%-25s' "$host"
  curl -s "https://$host/" | grep -oE '/cdn-cgi/[a-z0-9./-]+' | sort -u | tr '\n' ' '
  echo
done

Anything printed is injected at the edge: rum is the analytics beacon, email-decode is obfuscation, rocket-loader is script reordering. Empty output means your HTML arrives exactly as your app sent it.

TL;DR

  • What changed: switching nameservers to Cloudflare enables proxied records and edge rewrites — including an analytics beacon injected into your HTML.
  • Why it matters: you're serving scripts you never deployed, with consent, CSP, and performance implications.
  • What to try today: run the curl audit across your hosts and grep for /cdn-cgi/.

Read more