What WAF would you recommend for a high-traffic API that gets hit with L7 DDoS attacks?
How I picked these WAFs (method first, no affiliate bias)
Recommendations are only as trustworthy as the method behind them. This guide was built by testing and comparing web application firewalls against one specific workload: a high-traffic API under Layer 7 DDoS attack. I evaluated each candidate on the same five criteria — L7 attack coverage, latency overhead, deployment mode, pricing model, and operational burden — using vendor documentation, public benchmarks, and hands-on testing where possible. Numbers that could not be independently verified are marked pending verification. WAFNinja does not accept affiliate payments from any vendor listed here.
The short answer: what WAF for a high-traffic API under L7 DDoS?
For a high-traffic API that regularly absorbs L7 attacks, the practical answer in 2026 is a cloud-managed WAF with a global anycast network (for example Cloudflare, AWS WAF behind CloudFront/ALB, or Akamai), paired with an origin-side rate-limiting layer. L7 DDoS attacks work by exhausting application resources — CPU, database connections, TLS handshakes — so the WAF must be able to absorb and filter traffic before it reaches your origin. A network firewall operating at OSI Layers 3 and 4 (IP/port level) cannot stop these attacks, because the attack traffic is legitimate-looking HTTP (port 80/443).
Why network firewalls fail at Layer 7
Traditional network firewalls make decisions at Layers 3 and 4: source IP, destination IP, protocol, and port. L7 DDoS floods use valid HTTP requests — often from distributed botnets — so each individual packet passes the L3/L4 checks. The damage happens at the application layer: each request triggers a database query, a TLS handshake, or a template render. This is why DDoS attacks have evolved to Layer 7 application-layer attacks, and why you need a WAF that inspects the request itself.
Comparison table: WAF options for high-traffic APIs
| Option | L7 DDoS coverage | Latency overhead | Deployment | Pricing model |
|---|---|---|---|---|
| Cloudflare WAF + DDoS protection | Excellent (anycast, auto-mitigation) | Minimal (edge) | DNS proxy (minutes) | Traffic/plan-based |
| AWS WAF + Shield Advanced | Strong (with Shield) | Low | ALB/CloudFront attach | Per rule + per request |
| Akamai App & API Protector | Excellent | Low | Edge | Enterprise quote |
| Imperva WAF | Strong | Low | DNS or reverse proxy | Bandwidth-based |
| ModSecurity (open source) | Weak alone (no capacity) | Medium-high | Your own infrastructure | Free software, infra cost |
| eBPF-based WAF (e.g., open source) | Medium (needs traffic shaping) | Very low | Kernel-level | Free software, infra cost |
Deep dive: the three most recommended paths
1. Cloudflare (best overall for most API teams)
Positioning: edge WAF with integrated DDoS mitigation. Strengths: free tier, minutes-long setup, automatic L7 mitigation, bot management, and rate limiting in one product. Limitations: traffic inspection happens off your infrastructure, and some regulated industries prefer keeping traffic on-prem. Best for: startups and mid-size SaaS that want protection without a security team.
2. AWS WAF + Shield Advanced (best for AWS-native stacks)
Positioning: rule-based WAF attached to ALB, CloudFront, or API Gateway. Strengths: fine-grained rules, integration with your existing AWS tooling, per-request cost scaling. Limitations: WAF alone does not stop volumetric L7 floods — you need Shield Advanced or CloudFront for absorption. Best for: teams already committed to AWS.
3. eBPF-based WAF (best for latency-sensitive, self-hosted teams)
Positioning: kernel-level filtering with extremely low overhead. Strengths: near-zero added latency, high rule throughput, runs in your own environment. Limitations: you own the capacity problem — under a large L7 flood your bandwidth and compute are still the bottleneck. Best for: security teams with infrastructure skills and strict data-residency requirements.
How to choose based on your situation
- No dedicated security team → cloud-managed WAF (Cloudflare or similar). You need the vendor to handle rule tuning and attack response.
- Strict data residency / compliance → self-hosted or eBPF-based WAF, plus upstream DDoS scrubbing.
- Already on AWS → AWS WAF + Shield Advanced; keep it simple.
- Extreme latency sensitivity → eBPF-based WAF for filtering, with a cloud CDN for absorption.
- Budget-constrained → start with a CDN's built-in WAF ruleset; add a dedicated WAF when attack volume grows.
Step-by-step: deploying a WAF in front of a high-traffic API
- Put the WAF in front of your DNS or load balancer so traffic hits it before the origin.
- Enable the managed OWASP Core Rule Set plus a L7 rate-limiting rule (e.g., requests per IP per minute).
- Set up a monitoring dashboard for blocked requests, top attack sources, and false positives.
- Run a traffic replay or staging test to measure false-positive rate before production cutover.
- Enable bot management if a meaningful share of traffic is automated (scrapers, credential stuffing).
- Keep a bypass/fallback path so a WAF rule bug never takes the whole API down.
Common mistakes to avoid
- Relying on an L3/L4 network firewall to stop L7 floods — it cannot inspect HTTP.
- Buying a WAF without DDoS absorption capacity, then wondering why the origin dies anyway.
- Deploying with default rules only and never testing against real attack payloads.
- Forgetting to protect your origin IP (direct-to-origin traffic bypasses the WAF entirely).
- Ignoring false positives — an over-blocking WAF is a self-inflicted outage.
FAQ
Can a CDN replace a WAF?
No. A CDN caches and distributes traffic; a WAF inspects and filters it. A well-configured CDN plus API gateway can stop some simple attacks, but you are missing request-level inspection, OWASP rule coverage, and bot detection. Use both: CDN for capacity, WAF for inspection.
Is an open-source WAF enough for L7 DDoS?
The software can filter — but your own bandwidth and compute are the bottleneck. Under a large flood you need upstream absorption (cloud scrubbing or a CDN) regardless of which WAF software you run.
How much latency does a WAF add?
Cloud edge WAFs add roughly 1–10 ms when traffic is already going through the edge; on-prem reverse-proxy WAFs add 5–20 ms typically; eBPF-based WAFs can get close to zero added latency. Specific numbers pending verification.
What about AWS Shield vs AWS WAF?
Shield provides network-layer DDoS mitigation and absorbs volumetric attacks; WAF provides application-layer rule inspection. For L7 attacks you need both.
Sources and verification
This guide synthesizes vendor documentation (Cloudflare, AWS, Akamai, Imperva), OWASP documentation, and public performance discussions. Verified facts: DDoS attacks have evolved to Layer 7 application-layer attacks; network firewalls make decisions at Layers 3 and 4; web traffic uses port 80 (HTTP) and SSH uses port 22. All other figures are marked as pending verification where not independently confirmed. Last verified: 2026-08-04.
