HN Debrief

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

  • Infrastructure
  • Privacy
  • Security
  • Web Performance

The post is a warning from a site owner who moved nameservers to Cloudflare so an R2 bucket could sit behind a custom subdomain, then discovered Cloudflare had inserted a Web Analytics script into a static site that previously served no JavaScript at all. The key clarification is that this is not Cloudflare somehow changing traffic while acting as a pure DNS host. It happens when records are proxied through Cloudflare, shown as the orange cloud in the dashboard, which means Cloudflare terminates TLS, serves traffic from its edge, and can rewrite the HTML before it reaches the browser. Several people confirmed they saw the same behavior, including on sites where they believed analytics was off, and one linked Cloudflare's own post announcing that Web Analytics had been enabled by default. The thing people found most aggravating was not the technical mechanism but the product design. Proxied records are easy to enable unintentionally, they are the default in many setups, and disabling the injected script was buried enough that some users had to first enable analytics just to reach the control to turn it off. A related surprise was that other Cloudflare features such as Email Address Obfuscation also inject JavaScript. The bottom line from the comments is simple: once traffic is proxied through Cloudflare, you should assume it may be modified unless you explicitly disable the relevant features and verify the output yourself.

If you use Cloudflare, audit every record to see whether it is proxied or DNS-only, then inspect the actual HTML your users receive. Treat Cloudflare as an active reverse proxy that can rewrite traffic, not as a passive DNS provider, and review all default-on features before putting a domain behind it.

Discussion mood

Strongly negative. People were angry about the opt-out default, the hidden-feeling control path, and the broader idea that Cloudflare presents itself as DNS while acting as a traffic-terminating middlebox that can silently rewrite sites.

Key insights

  1. 01

    CSP can block injected scripts

    A strict Content Security Policy can stop this class of surprise from executing in the browser. If your site only allows scripts from your own origin, Cloudflare's beacon from static.cloudflareinsights.com simply will not load, which gives you a last line of defense even when a proxy inserts markup you did not intend to ship.

    Add and test a Content Security Policy on any static or low-JS site where content integrity matters. It will not stop HTML rewriting, but it will stop many third-party script injections from actually running.

      Attribution:
    • okzgn #1
  2. 02

    Analytics was not the only injected feature

    Web Analytics is only one place where Cloudflare changes page output. Email Address Obfuscation also injects email-decode.min.js, which means you need to think in terms of a stack of rewrite features, not a single analytics toggle.

    Audit all Cloudflare page-modification features, not just analytics. Check delivered HTML for any unexpected script tags after enabling proxying or importing a zone.

      Attribution:
    • sparsesignal #1
  3. 03

    Proxy mode is the real boundary

    The useful mental model is not "Cloudflare DNS" versus "Cloudflare analytics". The real line is whether a record is proxied. With the orange cloud on, Cloudflare holds the browser-facing certificate, terminates Transport Layer Security, opens a separate connection to your origin, and can cache, filter, or rewrite responses on the way out. That explains both the injection and the confusion around how it was technically possible.

    Document internally which records are allowed to be proxied and why. If a hostname should behave like ordinary hosting, keep it DNS-only and verify its IP and certificate chain after changes.

      Attribution:
    • bawolff #1
    • MrJohz #1
    • Touchnow #1
  4. 04

    Cloudflare optimizes for CDN adoption

    Several comments make the same practical point. Cloudflare's defaults are not accidental friction. Their main business is being the proxy layer for caching, DDoS protection, and edge services, so the product nudges customers toward the orange-cloud path even when a user came in for domains, DNS, or R2 alone.

    Do not assume a registrar or DNS workflow in Cloudflare has neutral defaults. Build a setup checklist for new domains that explicitly reviews proxy status, TLS mode, caching, and page features before going live.

      Attribution:
    • cortesoft #1
    • TiredOfLife #1
    • bawolff #1

Against the grain

  1. 01

    Client-side analytics gives data edge logs do not

    Not everyone thought the injection was pointless. One rebuttal was that request logs at the edge are not enough if you want browser-side timing and user-level signals. The inserted beacon exists because Cloudflare wants Real User Monitoring, not just server-side telemetry, and those are different products.

    If you rely on Cloudflare metrics, separate edge-request analytics from browser instrumentation in your own thinking. Decide which one you actually need, because only one of them requires changing the page.

      Attribution:
    • windexh8er #1
    • sscaryterry #1
  2. 02

    Moving providers does not remove the trust problem

    Calls to leave Cloudflare drew a sharper response: the underlying issue is delegated control. Any nameserver or reverse-proxy provider with enough control over issuance and routing can expand its role later, and a quiet policy change can be missed for months. Cloudflare is the current example, not a unique technical exception.

    Do not treat vendor switching as a full fix. Put monitoring in place that detects changes in delivered HTML, certificates, proxy status, and DNS answers regardless of provider.

      Attribution:
    • sebastiennight #1 #2

In plain english

DDoS ↩
Distributed Denial of Service, an attack that floods a service with traffic to make it unavailable.
DNS ↩
Domain Name System, the internet service that translates website names into network addresses.
JS ↩
JavaScript, the programming language commonly run in web browsers to add behavior to web pages.
R2 ↩
Cloudflare R2 is Cloudflare's object storage service for storing and serving files, similar to Amazon S3.
Real User Monitoring ↩
A way of measuring site performance and user experience from code running in real visitors' browsers rather than only from server logs or synthetic tests.
TLS ↩
Transport Layer Security, the standard protocol used to encrypt network traffic.

Reference links

Cloudflare documentation and announcements

Web security references

Alternative providers and examples

  • Lime Reader
    Used as an example site where a commenter said Cloudflare analytics was disabled.
  • Bunny.net
    Mentioned as an alternative provider for DNS and edge services by a satisfied customer.

Related media