Who Guards the Web: Cloudflare, WAFs, and the CDN-vs-Origin Measurement Problem
Published
Who Guards the Web: Cloudflare, WAFs, and the CDN-vs-Origin Measurement Problem
43,008,476 domains returned Server: cloudflare in the August 2026 census. That is 11.4% of every graded domain on the internet, making Cloudflare the single largest identifiable infrastructure provider by HTTP response signal, ahead of nginx at 30,843,313 (8.2%) and Apache at 28,539,494 (7.6%).
The temptation is to read that as: “Cloudflare protects 43 million websites.” It does not mean that. It means Cloudflare terminated 43 million HTTP connections at its edge. Whether those connections were protected by a WAF ruleset, whether HTTPS was enforced end-to-end to the origin, whether DDoS mitigation was active, whether the origin server behind the Cloudflare edge is itself hardened: none of that is visible in a Server header. The header records the last hop, not the security posture of what sits behind it.
This is the core measurement problem. A server header is a signal about network topology, not about protection. Understanding the difference matters for any IT architect or security team that reads infrastructure census data and tries to draw operational conclusions from it.
What “Server: cloudflare” Actually Implies
When a domain’s HTTP response carries Server: cloudflare, the Cloudflare edge terminated the connection. That means, at minimum:
- Traffic reached Cloudflare’s network before reaching the origin.
- Cloudflare’s TLS termination handled the HTTPS handshake (per RFC 8446, the TLS endpoint is whoever holds the certificate private key, and in proxy mode that is Cloudflare).
- The client’s IP address seen by the origin is a Cloudflare edge IP, not the client’s real IP (disclosed in the
CF-Connecting-IPheader per Cloudflare’s documented proxy protocol).
What it does not guarantee:
WAF rules active. WAF is a paid feature. Cloudflare’s free plan includes DDoS mitigation but WAF managed rulesets are restricted to Pro tier and above.
End-to-end encryption. “Flexible” SSL mode, which Cloudflare supports, terminates HTTPS at the edge but sends traffic to the origin over plain HTTP. The client sees a padlock; the origin leg is unencrypted.
Origin hardening. The origin server itself may be misconfigured, unpatched, or directly reachable on a non-proxied IP range. Cloudflare’s own guidance warns that origins exposed without IP allowlisting negate proxy-based protections.
Bot management. Like WAF, Cloudflare Bot Management is a paid add-on. The free and Pro tiers include limited bot mitigation; full Bot Management is Enterprise only.
The Server: cloudflare signal is therefore best read as: “This domain routes traffic through Cloudflare’s network.” Security posture beyond that requires domain-level inspection, not header scanning.
What the NS Data Adds: DNS Hosting vs Traffic Proxying
The census also collected authoritative NS records for each domain. 42,255,941 domains delegate DNS to cloudflare.com nameservers, roughly 42 million. That is a distinct measurement from the server header count, and it captures a different dimension of Cloudflare’s footprint.
Cloudflare offers two DNS products that produce a cloudflare.com NS delegation: their authoritative DNS service, where they host the zone, and their Registrar, where registered domains default to Cloudflare nameservers. Neither product necessarily routes any HTTP traffic through Cloudflare’s proxy. Within Cloudflare’s own dashboard, each DNS record has a proxy toggle: the orange cloud means traffic is proxied through Cloudflare’s edge; the grey cloud (DNS-only mode) means the record returns the origin IP directly and Server: cloudflare will not appear in responses.
The NS count and the server header count are measuring different things:
| Signal | What it measures | What it does not measure |
|---|---|---|
Server: cloudflare | HTTP traffic routed through Cloudflare’s edge | DNS, WAF depth, origin config |
NS: cloudflare.com | DNS zone hosted by Cloudflare | Whether any records are proxied |
The ~750k Gap and What It Reveals
The two Cloudflare counts are close but not identical: 43,008,476 server-header positives versus 42,255,941 NS positives, a difference of approximately 750,000 domains. That gap is not noise. It reflects two real populations:
Domains with Server: cloudflare but not NS: cloudflare.com: These domains have their DNS hosted elsewhere but route HTTP traffic through Cloudflare. This is possible via Cloudflare’s CNAME setup (partial zone), where a registrar or other DNS provider hosts the zone and selected records CNAME to Cloudflare. Enterprise customers frequently use this model to retain control of their DNS zone while routing specific subdomains through Cloudflare’s proxy.
Domains with NS: cloudflare.com but not Server: cloudflare: These domains use Cloudflare for DNS hosting but leave all or most records in DNS-only mode. Their HTTP responses come directly from the origin server. They count as Cloudflare DNS customers but not as Cloudflare proxy users.
The ~750k net difference between the two figures is the sum of these two populations offsetting each other. It confirms that DNS hosting and traffic proxying, while correlated at the product level, are not the same thing and should not be treated as interchangeable signals.
GoDaddy’s DNS Dominance: What 52 Million NS Records Mean
The largest single NS provider in the census is not Cloudflare. It is domaincontrol.com, GoDaddy’s DNS platform, at 52,445,186 domains, 13.9% of all graded domains and roughly 10 million more than Cloudflare’s NS count.
The interpretation is straightforward: GoDaddy is the world’s largest domain registrar by volume, and the overwhelming majority of domains registered with GoDaddy use its default nameservers without ever migrating DNS elsewhere. GoDaddy’s NS dominance is a registration artifact, not a security signal. Domains on domaincontrol.com have their DNS managed by GoDaddy; what the HTTP layer does is entirely separate.
What this reveals for IT architects is the degree of DNS hosting concentration at the internet level. Two providers, Cloudflare and GoDaddy, together account for over 94 million delegations from a 376-million-domain universe. DNS is the foundational resolution layer for all other protocols (RFC 1034, RFC 1035); outages or security incidents at either provider propagate broadly. The August 2023 Cloudflare DNS outage and GoDaddy’s multi-year breach disclosed in 2023 illustrate why concentration at this layer is a systemic risk, not just an individual domain concern.
For security teams assessing vendor concentration risk, the NS census data is the most direct available signal.
The 45.6% With No Server Header: The Dark Matter of Web Infrastructure
171,808,677 domains in the census returned no Server header at all. That is 45.6% of all graded domains, the largest single “category” in the entire server-header distribution, larger than Cloudflare, nginx, and Apache combined.
This population is opaque for two distinct reasons:
Active suppression. Security guidance from OWASP, CIS Benchmarks, and the OWASP Secure Headers Project consistently recommends removing or neutralising the Server header to reduce information leakage. nginx’s server_tokens off directive, Apache’s ServerTokens Prod combined with mod_headers, Caddy’s default behaviour, and Cloudflare’s security headers rules can all produce a response with no Server header. Domains that follow this guidance actively contribute to the no-header population. The absence of a Server header is a positive signal about hygiene, not a suspicious one.
CDN stripping. Many CDNs and load balancers rewrite or remove upstream Server headers as part of their normalisation pass. A domain behind AWS CloudFront, Fastly, or a corporate reverse proxy may return no Server header not because the operator suppressed it but because the CDN did. The census cannot distinguish these cases.
The practical consequence: 45.6% of the internet’s domains are infrastructure-dark from a server-header perspective. Any analysis that uses server headers to characterise “what software runs the web” is working from 54.4% of the signal.
Measurement Limits for Security Posture Assessment
Server headers and NS records are useful signals for infrastructure topology research. They are poor proxies for security posture assessment, for four reasons:
1. Headers reflect the edge, not the origin. For any domain behind a CDN or reverse proxy, the Server header describes the proxy software, not the origin. The origin could be running an unpatched version of the software the proxy replaced.
2. Absence does not mean safety. A domain with no Server header might be aggressively hardened or might be a parked page with no meaningful attack surface.
3. Cloudflare’s product surface is not uniform. The 43 million Server: cloudflare responses span Free, Pro, Business, and Enterprise plans with substantially different security capabilities. Treating the cohort as uniformly “protected” overstates the security posture of the free-plan majority.
4. HTTP-layer inspection misses non-HTTP attack surfaces. Server headers say nothing about mail security (SPF, DKIM, DMARC), DNS security (DNSSEC), certificate hygiene, or network-layer exposure. A domain can return Server: cloudflare on HTTP while being fully spoofable by email.
What IT Teams Should Take From This Data
The census data supports several specific conclusions:
Cloudflare is the dominant HTTP-layer intermediary. At 11.4% of all graded domains, no other single infrastructure layer comes close. For threat intelligence teams tracking infrastructure attribution or identifying shared hosting patterns, the Server: cloudflare signal identifies a large co-located population reliably.
DNS concentration is a systemic risk factor. GoDaddy at 52 million and Cloudflare at 42 million NS delegations together cover a substantial fraction of the internet’s authoritative DNS. Organisations assessing third-party concentration risk should treat DNS-provider diversification as a relevant control.
The 750k gap between Cloudflare’s two signals is actionable. Security teams inventorying their own portfolio can use the presence or absence of both signals (NS delegation and server header) to identify domains that use DNS-only mode, potentially exposing origin IPs, versus domains where traffic is fully proxied.
Server headers are a starting point, not a conclusion. For any domain where infrastructure matters, start with NS records (actual DNS delegation), follow with HTTP response headers (edge topology), then validate with TLS certificate transparency logs, and finally inspect security response headers (HSTS, CSP, permissions policy) to assess what the operator has actually configured.
The August 2026 census counts 376,928,750 graded domains. What 43 million Server: cloudflare responses actually tell us is that Cloudflare has become load-bearing infrastructure for a substantial fraction of the web’s HTTP layer. What those responses cannot tell us is whether that layer is configured to protect the domains behind it. That distinction is the difference between a topology map and a security assessment.
Methodology: HTTP checks performed with a controlled request stack. NS records collected from authoritative resolvers per domain. All checks as of 2026-08-16, methodology v9. Server header counts: cloudflare 43,008,476, nginx 30,843,313, apache 28,539,494. NS counts: domaincontrol.com 52,445,186, cloudflare.com 42,255,941. References: RFC 8446 (TLS 1.3), RFC 1034, RFC 1035 (DNS), OWASP Secure Headers Project.
What This Means
For IT architects and security managers, the central lesson from this data is that infrastructure topology and security posture are different measurements. Knowing that a domain routes traffic through Cloudflare tells you something about the network path; it tells you almost nothing about whether the WAF is active, whether the origin is hardened, or whether email for that domain is protected. A domain can return Server: cloudflare while having no DMARC policy, no DNSSEC, and an unpatched origin server listening on a public IP that bypasses the CDN entirely.
The DNS concentration finding has direct implications for business continuity and third-party risk management. GoDaddy controls DNS for 52 million domains and Cloudflare for 42 million — together, nearly 95 million delegations from a 376-million-domain universe. If your organisation depends on either provider for authoritative DNS, that dependency should be documented in your risk register and tested in your continuity plans. Past outages at both providers have demonstrated the breadth of downstream impact.
For security teams auditing their own domain portfolio, the practical takeaway is to treat Cloudflare presence as the beginning of your investigation, not the end. Check whether your Cloudflare plan tier includes the WAF features you assume you have. Verify that origin servers are not directly reachable on public IPs that bypass the proxy. Confirm that your Cloudflare SSL mode is Full (Strict), not Flexible — the difference between end-to-end encryption and an unencrypted origin leg is invisible to anyone checking the padlock icon in a browser.
Data to Cite
- “43,008,476 domains returned ‘Server: cloudflare’ in the August 2026 census — 11.4% of all graded domains, making Cloudflare the single largest identifiable infrastructure provider by HTTP signal.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “GoDaddy’s domaincontrol.com leads all DNS providers at 52,445,186 NS delegations — 13.9% of all graded domains, roughly 10 million more than Cloudflare’s NS count.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “Cloudflare’s server-header count (43,008,476) and its NS-delegation count (42,255,941) differ by approximately 750,000 — reflecting domains that proxy through Cloudflare without using its DNS, and vice versa.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “171,808,677 domains — 45.6% of all measured — returned no Server header at all, making ‘no header’ the single largest category in the server-header distribution.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “Two DNS providers — GoDaddy and Cloudflare — together account for over 94 million NS delegations from a 376-million-domain universe, a systemic concentration risk.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “A domain returning ‘Server: cloudflare’ may be on Cloudflare’s free plan with no WAF rules active, using Flexible SSL with an unencrypted origin leg, and fully spoofable by email — server headers cannot distinguish these cases.” — defaults.exposed August 2026 Domain Security Census (432M domains)
FAQ
Does ‘Server: cloudflare’ mean a site is protected by a WAF?
No. Cloudflare’s WAF managed rulesets are a paid feature, restricted to Pro tier and above. The 43 million domains returning Server: cloudflare span Free, Pro, Business, and Enterprise plans. Free-plan users get DDoS mitigation but not full WAF coverage. The header alone cannot tell you which plan is in use.
How does Cloudflare’s server-header count compare to its DNS customer count?
In the August 2026 census, 43,008,476 domains returned Server: cloudflare (HTTP traffic proxied through Cloudflare) while 42,255,941 domains delegated DNS to Cloudflare nameservers. The ~750,000 gap reflects domains that use CNAME-based Cloudflare routing without Cloudflare DNS, and domains that use Cloudflare DNS in DNS-only mode without proxying HTTP traffic.
Why does GoDaddy have more NS delegations than Cloudflare? Because GoDaddy is the world’s largest domain registrar by volume, and most registrations stay on the registrar’s default nameservers indefinitely. GoDaddy’s 52 million NS delegations are mostly a registration artifact — they do not imply anything about those domains’ web infrastructure or security posture.
What does the 45.6% no-Server-header rate mean for security tools? Any scanner that uses the Server header to classify infrastructure is working with a systematic blind spot covering 45.6% of measured domains. For those domains, the header provides no signal about the origin software. Security assessments should treat header absence as a posture signal (suppression is recommended practice) rather than an information gap requiring investigation.
How should I verify my Cloudflare configuration is actually protecting my domain? Check four things: (1) your plan tier to confirm WAF managed rulesets are included; (2) your SSL/TLS encryption mode is Full (Strict), not Flexible; (3) your origin server is not reachable on a public IP that bypasses Cloudflare; (4) your email records (SPF, DKIM, DMARC) are correctly configured — Cloudflare’s HTTP protection does not extend to email spoofing.
Check your domain free at defaults.exposed — see whether your domain’s security posture goes beyond topology, including email authentication, DNSSEC, and HTTPS configuration that a Server header cannot reveal. Takes 30 seconds. No account needed.
How to cite this report
Press / blog: defaults.exposed (2026). Who Guards the Web: Cloudflare, WAFs, and the CDN-vs-Origin Measurement Problem. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/cloudflare-cdn-waf-measurement-problem-2026
Academic: defaults.exposed. (2026, August 18). Who Guards the Web: Cloudflare, WAFs, and the CDN-vs-Origin Measurement Problem. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/cloudflare-cdn-waf-measurement-problem-2026
In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,781)
About the defaults.exposed August 2026 Census
The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.
Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026