The most counterintuitive finding in Zyte's State of Web Access 2026 research is also the most prominent one.
Web Application Firewalls (WAFs) appear on 92.4% of the landing pages we audited - by far the most ubiquitous access control in the dataset. Nine in 10 of the world's most popular sites run one.
That sounds like a formidable obstacle. It isn't - or at least, not in the way the number implies.
Understanding why tells you more about the modern web's infrastructure economics than almost any other data point in the research.
What is a Web Application Firewall?
A Web Application Firewall is, at its core, a reverse proxy that inspects HTTP traffic and blocks requests matching patterns associated with attacks - SQL injection attempts, cross-site scripting payloads, malformed headers, known exploit signatures.
The first commercial WAFs appeared in the early 2000s, marketed to enterprises as protection against application-layer attacks that network firewalls couldn't see. They were expensive, complex, and slow. A mid-2000s enterprise WAF deployment was a six-figure project.
Then the economics changed. The catalyst was the rise of cloud CDNs - content delivery networks that sit between the internet and a web server, caching content closer to users and absorbing traffic spikes. Cloudflare, founded in 2009, built its business on providing CDN services for free, at scale, to anyone. To make that work, it needed to inspect and filter traffic anyway. WAF capability wasn't a premium add-on - it was a byproduct of the architecture. By 2017, Cloudflare's free tier included WAF functionality that would have cost thousands of dollars annually a decade earlier.
The result was that WAF adoption stopped being a decision. Rather, it became a default.
When a developer signs up for Cloudflare, or deploys on Amazon CloudFront, or routes traffic through a modern hosting platform, they get a WAF. They may never configure it. They may not know exactly what it's doing. They almost certainly haven't tuned it for any specific use case. But it's there, registering in our detection methodology, contributing to the 92.4%.
One vendor holds a third of the WAF market
Our data identified 18 distinct WAF vendors across the 11,100 sites in the dataset.
Cloudflare accounts for 34.6% of named deployments - more than the next several vendors combined. Amazon CloudFront adds another 9.6%. AWS Elastic Load Balancer 4.3%. The dedicated security vendors - Akamai at 4.9%, F5 at 1.6%, Imperva at 1.4% - are distant participants.
That vendor distribution tells you everything about what kind of WAF most sites are running. Akamai, F5, and Imperva sell to security teams at large enterprises. They're configured deliberately, tuned continuously, and represent a genuine security investment. Cloudflare and CloudFront are running on the vast majority of the web's sites as CDN infrastructure, with WAF rules that may be set to default or close to it.
The other striking number: 31.6% of WAF detections return no attribution at all. A third of the WAFs in the dataset couldn't be fingerprinted to a named vendor. Some of those are custom-built or deeply obfuscated enterprise deployments. Some are running ModSecurity - the open-source WAF engine that underpins a vast portion of Apache and NGINX infrastructure worldwide - configured in ways that strip identifying headers. ModSecurity's parent organization announced it was dropping support in 2024, but the codebase is too embedded in global infrastructure to disappear quickly.
What WAFs actually do - and what they don't
Here is the nuance that the 92.4% figure obscures: a WAF configured for security and a WAF configured for access control are different instruments doing different things.
The default ruleset on most cloud WAFs is oriented toward OWASP Top 10 threats - the canonical list of web application vulnerabilities that includes SQL injection, XSS, broken authentication, and similar attack patterns. A data** extraction pipeline that politely requests pages, renders JavaScript, and handles cookies correctly does not look like an SQL injection attack**. It doesn't trigger those rules.
The WAF capabilities that actually affect web data access are different ones: rate-based rules that fire when request frequency exceeds a threshold, IP reputation checks that flag known datacenter ranges, TLS fingerprint analysis, and behavioral anomaly detection. These are either disabled by default, require deliberate activation, or belong to premium bot management tiers that sit above the basic WAF product.
This is why WAF presence and WAF posture are two different things. A site running Cloudflare at default settings is not the same as a site running Cloudflare with Bot Management enabled, thresholds calibrated, and custom rules written. The 92.4% includes both - and the ratio between them is what actually determines how hard the web is to access at scale.
Japan, the outlier that proves WAFs ride on infrastructure
If WAF adoption were primarily a security decision, you'd expect to see variation driven by threat exposure - high-value financial sites at near-100%, low-value informational sites at much lower rates. That isn't what the data shows.
The industries with the lowest WAF adoption in our dataset are airlines (76%) and military (77%) - not industries you'd expect to be cavalier about security.
The explanation is infrastructure vintage: these sectors built their web presence on specialist hosting systems - in some cases government-adjacent or aviation-specific platforms - that predate the cloud CDN era. Their WAF gap is an artifact of when their infrastructure was built, not how security-conscious they are.
Japan is the one clear national outlier at 86% - seven points below the global average, and a gap that persists across industries. Japan has a strong domestic CDN and hosting ecosystem: IIJ, GMO, and other providers that serve the Japanese market without routing through the global Cloudflare/Akamai stack. Sites hosted on those platforms simply don't acquire WAF capability as a byproduct of their infrastructure choices. Read properly, the 86% maps Japan's hosting supply chain rather than any gap in its security.
WAF and CDN are becoming one product
The boundary between WAF, CDN, and bot management has been dissolving for years. Cloudflare no longer describes itself as a CDN company; it calls itself a network security company. Akamai's most significant product evolution in the past decade has been from CDN to security platform. The WAF is becoming the substrate on which a richer set of access controls runs.
What this means practically is that the presence of a WAF is increasingly not the question worth asking. The question is what's running on top of it. A Cloudflare WAF with Bot Score enabled and a challenge threshold set at 30 is a substantively different access environment than the same WAF with default settings.
What this means for web data access
The 92.4% WAF adoption rate is real. But it measures infrastructure coverage, not defensive intent. The majority of those 92.4% are sites that acquired a WAF as a side effect of choosing a CDN, and have never configured it to actively resist automated access.
That doesn't mean WAFs are irrelevant to web data pipelines. Even default WAF rules can trigger on sufficiently aggressive request patterns. Rate-based rules fire at scale. IP reputation lists catch datacenter traffic. And for the minority of sites that have deliberately configured their WAF for access control, the product is a capable and continuously-updated obstacle.
The practical read: encountering a WAF in the wild is a signal to understand, not a conclusion to draw. What matters is what that WAF is doing - and the only way to know is to try.
