Cloud WAF vs On-Premise WAF: Which Actually Protects You From DDoS?

The WAF market has shifted heavily toward cloud-delivered models, but on-premise WAFs are far from dead. Each deployment model carries distinct implications for DDoS resilience, and the choice between them shapes how your organization absorbs, deflects, or collapses under attack.

Choosing between a cloud WAF and an on-premise WAF is not just a procurement decision. It determines where traffic inspection happens, how volumetric attacks are absorbed, which application-layer threats get caught, and how much of your defense architecture is visible to attackers before they even begin.

This guide breaks down both models from a DDoS protection perspective, compares their strengths and weaknesses with real technical detail, and explains what DDactic's reconnaissance scans reveal about each.

How Cloud WAFs Work

Cloud WAFs operate as reverse proxies. You change your DNS records to point at the WAF provider's network instead of your origin server. All inbound traffic flows through the provider's edge infrastructure first, where it is inspected, filtered, and forwarded to your actual server.

The core architecture is straightforward: your domain resolves to the cloud WAF provider's IP addresses. The provider terminates the TLS connection at their edge, inspects the HTTP request, applies rules, and if the request passes, opens a new connection to your origin server to fetch the response.

Key cloud WAF vendors

The primary cloud WAF benefit for DDoS protection is scale. When a volumetric attack hits, it lands on the provider's globally distributed network, not on your origin. A 100 Gbps flood that would overwhelm any single data center is absorbed across dozens of edge locations, each handling a fraction of the total volume.

Cloud WAFs also handle TLS termination at the edge. This matters because TLS handshakes are computationally expensive. In a TLS-based DDoS attack, the cloud WAF's infrastructure absorbs the handshake cost, preventing your origin from being overwhelmed by connection setup overhead alone.

How On-Premise WAFs Work

On-premise WAFs sit physically in your data center, typically deployed inline between your edge router or load balancer and your application servers. Traffic passes through the appliance, which inspects and filters it before forwarding clean traffic to the backend.

Unlike cloud WAFs, on-premise solutions see the full request after it arrives at your network boundary. There is no intermediary performing TLS termination or content inspection upstream. The appliance handles everything locally.

Key on-premise WAF vendors

The primary on-prem WAF advantage is depth of inspection. Because the appliance sits inside your network, it can inspect traffic that cloud WAFs never see: internal east-west traffic, non-HTTP protocols, and application behavior patterns that require stateful session tracking across many requests.

On-premise appliances also avoid the latency introduced by routing traffic through a third-party network. For latency-sensitive applications, particularly financial trading platforms or real-time communication systems, the round-trip penalty of a cloud proxy can be unacceptable.

The DDoS Perspective

This is where the cloud WAF vs on-premise WAF comparison gets consequential. Each model has a fundamentally different relationship with DDoS attacks.

Volumetric attacks (L3/L4)

Cloud WAFs have a decisive advantage against volumetric DDoS. A SYN flood, UDP amplification, or DNS reflection attack that generates 50-500 Gbps of traffic will be absorbed by the cloud provider's edge network. The attack never reaches your origin because your origin's IP is hidden behind the cloud proxy.

On-premise WAFs, by contrast, sit at the end of your network pipe. A 10 Gbps volumetric flood against a data center with a 1 Gbps uplink will saturate the link before the on-prem appliance even sees the traffic. The WAF may be perfectly capable of inspecting and filtering traffic at line rate, but the traffic never reaches it because the upstream link is congested.

Application-layer attacks (L7)

Here the advantage shifts. Application-layer DDoS attacks, such as HTTP floods, slowloris, and API abuse, use legitimate-looking requests that are hard to distinguish from real traffic. Cloud WAFs rely on behavioral heuristics, rate limiting, and JavaScript challenges to detect these. But because the cloud WAF sees traffic from thousands of customers simultaneously, its per-customer behavioral models can be less precise than a dedicated on-prem appliance that knows only your traffic patterns.

On-premise WAFs, particularly those with behavioral learning capabilities like Radware DefensePro, build baseline models of your specific application's normal behavior. They learn typical request rates per URL, expected parameter patterns, and normal session durations. When an L7 attack deviates from these baselines, the on-prem appliance can detect it faster and with fewer false positives than a cloud WAF applying generic rules.

The hybrid ideal

The strongest DDoS protection architecture combines both: a cloud WAF or scrubbing service upstream to absorb volumetric attacks, with an on-premise WAF downstream for deep application-layer inspection. This is what major enterprises and critical infrastructure operators deploy, but it is expensive and operationally complex. Most organizations choose one or the other.

Detection Fingerprints: How DDactic Identifies Each Type

During automated reconnaissance, DDactic's scanning engine identifies which WAF deployment model protects each asset. This identification is based on multiple signal layers, as detailed in our HTTP fingerprinting guide.

Cloud WAF signals

Cloud WAFs are typically identifiable from a single HTTP response. The provider's network adds characteristic headers, cookies, and behaviors:

# Cloudflare
cf-ray: 8a1b2c3d-IAD
cf-cache-status: DYNAMIC
server: cloudflare

# AWS CloudFront + WAF
x-amz-cf-id: abc123...
x-amz-cf-pop: IAD55-P2
x-cache: Miss from cloudfront

# Akamai
x-akamai-request-id: 1234abcd
x-akamai-transformed: 9 - 0 pmb=mTOE,1

# Imperva Cloud (Incapsula)
x-iinfo: 5-12345678-0 0NNN RT(1681234567890 0)
Set-Cookie: incap_ses_123_456789=...
Set-Cookie: visid_incap_456789=...

Beyond headers, cloud WAFs reveal themselves through DNS resolution (your domain resolves to the provider's IP space), TLS certificate details (the edge certificate is issued to the WAF provider's infrastructure), and challenge page behavior (each vendor's bot challenge has a distinctive HTML structure and JavaScript pattern).

On-premise WAF signals

On-premise appliances leave subtler but still identifiable traces:

# Radware
Server: rdwr
x-sl-compstate: ...

# F5 BIG-IP
Set-Cookie: BIGipServerPool_Web=123456789.12345.0000
x-cnection: close

# Fortinet FortiWeb
Server: FortiWeb
Set-Cookie: FORTIWAFSID=...

# Imperva SecureSphere (on-prem)
Server: SecureSphere
Set-Cookie: MgHyphenate=...

An important distinction: when DDactic scans detect no cloud WAF headers, this means no cloud WAF is visible from the outside. It does not mean the target is unprotected. On-premise WAFs, network-level DDoS appliances, and ISP-level scrubbing services may all be in place but invisible to external HTTP reconnaissance. Our reports are careful to distinguish between "no cloud WAF detected" and "no protection," because they are very different situations.

Layered architectures

Some responses reveal both cloud and on-prem protection simultaneously. A response might include Cloudflare's cf-ray header alongside an F5 BIGipServer cookie, indicating traffic flows through the cloud WAF first, then through an on-premise load balancer. This layered architecture is the strongest configuration but also the most complex to maintain.

Common Misconfigurations

Both deployment models suffer from configuration mistakes that undermine their protection. The mistakes are different for each model, but equally damaging.

1. Origin IP exposure behind cloud WAF

The most critical cloud WAF failure. Your domain points to Cloudflare, but your origin server's real IP is discoverable through DNS history records, SPF/MX records pointing to the same IP, or subdomains that were never moved behind the proxy. Once an attacker knows the origin IP, they bypass the cloud WAF entirely and attack the server directly.

# Common origin exposure vectors
dig +short mail.example.com    # MX record points to origin
dig +short staging.example.com # Subdomain not behind WAF
dig +short ftp.example.com     # Legacy record still resolving

# Historical DNS lookups via SecurityTrails, ViewDNS, etc.
# Can reveal previous IPs before cloud WAF was deployed

2. On-premise WAF with no upstream scrubbing

An on-premise WAF without any upstream volumetric protection is vulnerable to being overwhelmed before it can do its job. If your ISP does not offer DDoS scrubbing and you have no cloud-based scrubbing service in front of your on-prem appliance, a volumetric attack will saturate your network link. The WAF appliance never gets a chance to inspect and filter because the packets never arrive in a usable state.

3. Split-brain routing

This happens when some traffic flows through the cloud WAF while other traffic reaches the origin directly. Common causes include:

• API subdomains (api.example.com) resolving directly to origin while www.example.com goes through the cloud WAF
• IPv6 records (AAAA) pointing to origin while IPv4 (A) records point to the cloud WAF
• Webhooks and callback URLs configured with origin IP instead of the WAF-proxied domain
• Internal services making requests to the origin IP directly, bypassing both cloud and on-prem WAF

4. WAF in monitor-only mode

This misconfiguration affects both cloud and on-premise WAFs equally. The WAF detects attacks and logs them but blocks nothing. It happens when teams enable the WAF in "simulate" or "detect" mode during initial deployment and never graduate to blocking mode. From an external scan, the WAF appears to be present, but during an actual attack it provides zero protection.

5. Cloud WAF with permissive origin firewall

Your cloud WAF is configured correctly, but your origin server's firewall accepts connections from any IP, not just the cloud WAF's IP ranges. An attacker who discovers the origin IP can connect directly, completely bypassing inspection. The fix is to restrict your origin firewall to accept connections only from your cloud WAF provider's published IP ranges.

# Example: Restrict origin to Cloudflare IPs only (UFW)
ufw default deny incoming
ufw allow from 173.245.48.0/20 to any port 443
ufw allow from 103.21.244.0/22 to any port 443
ufw allow from 103.22.200.0/22 to any port 443
# ... add all Cloudflare IP ranges
ufw enable

What Your OPI Score Tells You

DDactic's Online Protection Index (OPI) evaluates your DDoS resilience across multiple dimensions. The WAF deployment model directly affects several scoring factors, as described in our OPI benchmarks analysis.

How cloud WAFs affect OPI scoring

Deploying a cloud WAF typically improves OPI scores in these areas:

• Volumetric absorption: The cloud provider's network capacity counts toward your volumetric DDoS resilience score
• Origin concealment: If the origin IP is properly hidden, the "direct attack surface" component scores well
• TLS offloading: Edge-terminated TLS protects against TLS-based DoS
• Geographic distribution: Anycast routing improves resilience against geographically concentrated attacks

But cloud WAFs can hurt scores when:

• Origin IP is discoverable through DNS history or related records
• WAF is in detect-only mode (detectable through challenge behavior testing)
• API endpoints bypass the WAF entirely
• Cache configuration forces all requests to origin

How on-premise WAFs affect OPI scoring

When DDactic scans detect no cloud WAF, the OPI scoring adjusts accordingly. The volumetric protection score decreases because there is no visible upstream scrubbing capacity. However, the presence of on-premise appliance signatures (detectable through response headers) indicates that application-layer inspection is in place, which partially offsets the volumetric gap.

It is worth repeating: no cloud WAF visible does not mean unprotected. An organization with Radware DefensePro on-premise, ISP-level DDoS scrubbing, and a well-tuned network firewall may be more resilient than one hiding behind a misconfigured cloud WAF with an exposed origin. The OPI score accounts for what is measurable from external reconnaissance, but it notes the distinction between confirmed absence of protection and simply non-visible protection.

Making the Right Choice

The cloud WAF vs on-premise WAF decision depends on your specific risk profile, infrastructure, and operational capacity.

For most organizations with internet-facing applications and limited security staff, a cloud WAF is the practical choice. It provides volumetric protection that no single appliance can match, and the operational burden is significantly lower.

For organizations with strict data residency requirements, latency-sensitive applications, or the staff to manage hardware appliances, on-premise WAFs offer deeper inspection and tighter control.

For critical infrastructure, financial services, and organizations that are frequent DDoS targets, the hybrid approach is worth the cost and complexity. Cloud scrubbing upstream handles volumetric attacks while the on-premise WAF handles application-layer threats with full visibility into internal traffic patterns.

"The question is not cloud or on-prem. It is whether the WAF you chose is actually configured, tuned, and tested for the attacks you will face."