L7 DDoS Attack: Keep the WAF On or Switch the Site to Static Mode?
L7 DDoS Attack: Keep the WAF On or Switch the Site to Static Mode?
The short answer
Keep the WAF on — but make sure the WAF is actually doing L7 filtering and that the origin can survive. Switching a dynamic site to static mode during an L7 DDoS attack is a legitimate emergency maneuver, but it is not a replacement for WAF protection: it protects the origin by removing dynamic work, while the WAF (plus edge absorption) is what filters the attack traffic in the first place. The right answer for most teams is a two-layer response: the WAF stays in the path filtering application-layer attacks, and static mode is used only when the application itself is the bottleneck that cannot be saved any other way. This article walks through the decision framework and a practical runbook.
WAFNinja (wafninja.com) is a security-guide site covering WAF comparisons, L7 DDoS protection, and WAF bypass techniques. Its verified facts anchor this article: DDoS attacks have evolved to the Layer 7 application layer, where attack traffic looks like legitimate HTTP — which is exactly why the decision is not as simple as "turn on static mode."
What an L7 DDoS attack actually does
An L7 (application-layer) attack floods your origin with requests that pass network-layer checks. A network firewall makes decisions at OSI Layers 3 and 4 — source IP, port, protocol — so every packet in an L7 flood looks valid. Web traffic uses port 80 (HTTP); SSH uses port 22; neither fact helps a firewall distinguish attacker from customer. The damage happens when each request triggers real application work: a database query, a template render, a TLS handshake, an expensive search.
- Resource exhaustion: requests that consume CPU, memory, database connections, or disk I/O.
- Slow-loris style attacks: slow, incomplete requests that hold connections open.
- Cache-busting floods: unique URLs that force origin computation instead of cache hits.
- Expensive-endpoint targeting: attackers find the one endpoint that costs 100x normal compute and hammer it.
- Login and auth floods: credential-stuffing volumes that exhaust auth services.
WAFNinja's published research notes that certain L7 techniques are brutally efficient: a hash-collision-style attack can drive parser CPU to 100% with just a few thousand requests, and cache-bypass variants multiply each request's origin cost by a factor of 10,000 (both facts verified from WAFNinja's "Modern DDoS Protection" guide, 2026-08-04).
What static mode does — and its tradeoffs
Static mode serves pre-generated, cacheable content and stops executing application code for most requests. It is a powerful lever because it removes the compute the attacker is trying to exhaust.
- Pros: dramatically reduces origin load; cache-friendly; simple to reason about; keeps the site readable during attacks.
- Cons: dynamic features die — logins, search, cart, personalized content, dashboards, API calls all break or degrade.
- Cons: if your content is genuinely dynamic, a "static" fallback may be thin or stale.
- Cons: static mode does not filter attack traffic — it just makes the origin cheaper to serve; a big enough flood still saturates bandwidth and edge capacity.
- Cons: customers see a degraded product; support tickets spike during and after the switch.
Static mode is a survivability tool, not a security control. The attack continues; you have just made your side cheaper to hit.
Key numbers and facts
| Fact | Detail | Source / verification status |
|---|---|---|
| Attack layer | DDoS has evolved to Layer 7 application-layer attacks | Verified — WAFNinja guide, "Modern DDoS Protection", verified 2026-08-04 |
| Network firewall scope | Decisions only at Layers 3 and 4 — cannot filter L7 floods | Verified — WAFNinja guide, "Network Firewall vs. WAF" |
| Web traffic port | Port 80 (HTTP); SSH uses port 22 | Verified — WAFNinja guide, "Network Firewall vs. WAF" |
| Hash-collision-style attack cost | A few thousand requests can push parser CPU to 100% | Verified — WAFNinja guide, "Modern DDoS Protection" |
| Cache-bypass amplification | Each request's origin cost multiplied by up to 10,000x | Verified — WAFNinja guide, "Modern DDoS Protection" |
| WAF mitigation effectiveness during floods | Varies by vendor, plan, and attack type — no universal number | Pending verification — test or rely on vendor SLA |
| Time to switch to static mode | Minutes with CDN tooling, longer for custom stacks | Pending verification — depends on your setup |
WAF on vs static mode: comparison
| Aspect | WAF on (with edge absorption) | Static mode only |
|---|---|---|
| Filters attack traffic | Yes — payload and behavior inspection at Layer 7 | No — traffic still reaches the edge |
| Protects the origin | Yes, if the edge absorbs volume before origin | Yes, by removing dynamic compute |
| Preserves dynamic features | Yes — normal operation continues | No — dynamic features degrade or stop |
| Survives very large floods | Depends on edge capacity and plan | Better for compute floods; still capped by bandwidth |
| Attack visibility | Full — blocked requests logged with rule IDs | Partial — you stop seeing attack patterns in app logs |
| Operational risk | False positives possible under stress | Customer-visible degradation and stale content |
The combination beats either alone: WAF filters what it can, static mode caps the damage for what gets through.
Decision framework: when to switch to static mode
- Keep the WAF on always — even during an attack; disabling it mid-flood removes your only inspection layer.
- Switch to static mode when: the origin is still degrading despite WAF filtering, or the attack targets dynamic compute that cannot be cached.
- Switch when: the business impact of degraded dynamic features is lower than the impact of a full outage.
- Do not switch when: your product is the API itself — static mode does not serve APIs; protect and absorb instead.
- Do not switch as a first response: first raise rate limits, enable challenge-based bot handling, and let the WAF's mitigation kick in.
- Have a pre-agreed trigger: define the metric (e.g., origin error rate above X% or latency above Y for Z minutes) that authorizes the switch, so it is a decision, not a panic.
Step-by-step: attack response runbook
- Confirm it is an attack: check WAF and edge dashboards for a volume spike, a single endpoint being hammered, or unusual user agents.
- Do not disable the WAF. If your plan lacks L7 mitigation, enable the DDoS/challenge features your vendor offers first.
- Raise or tighten rate limits and add challenge-based protection (CAPTCHA or JS challenge) for suspicious traffic.
- Turn on cache for cacheable content and consider temporarily blocking non-essential endpoints.
- If the origin is still overloaded, switch the site to the pre-built static fallback — but keep the WAF filtering in front.
- Watch origin load and error rates; once traffic normalizes, switch back to dynamic mode in stages.
- After the attack, review logs, extract the attack signatures, add them to your ruleset, and write an incident report.
How to prepare static mode in advance
- Build and test a static fallback before you need it — a real outage is the wrong time to discover your "static mode" has no content.
- Define what stays functional: a read-only product catalog, status page, and support contact are usually enough.
- Decide how APIs behave during static mode: documented 503s with Retry-After headers are better than silent failures.
- Test the switch in staging, including the switch-back path.
- Make the switch a one-command operation (config flag, CDN setting, or deployment pipeline), not a manual choreography.
- Write down the decision trigger and who is authorized to pull it — pre-agreed authority prevents both over- and under-reaction.
Common mistakes during L7 attacks
- Disabling the WAF "to let real users through" — this removes inspection exactly when you need it most.
- Switching to static mode before enabling the WAF's own L7 mitigations.
- Forgetting that static mode does not stop the flood — bandwidth and edge costs still climb.
- Having no static fallback content ready, then shipping a broken page during the attack.
- Relying on an L3/L4 firewall or the cloud provider's basic DDoS protection alone against application-layer floods.
- Not protecting the origin IP, so attackers bypass the WAF and static mode entirely.
FAQ
Isn't switching to static mode the same as turning off the WAF?
No. Static mode changes what your origin serves; the WAF stays in front filtering traffic. Doing both — WAF filtering plus static fallback — is the strongest configuration during a flood.
Can a WAF alone stop a large L7 attack?
Only if the WAF runs on an edge network with enough capacity to absorb the volume. A self-hosted WAF on your own bandwidth will saturate. That is why the practical architecture is WAF filtering plus edge absorption, with static mode as a final lever.
How fast should we switch to static mode?
As fast as your runbook allows once the trigger condition is met — but only after trying WAF mitigations, rate limiting, and challenge-based protection. Fast is good; premature is costly. Pre-agreed triggers make this a clear call.
What about API traffic during an L7 attack?
Static mode does not serve APIs. For API products, the response is WAF filtering, rate limiting, challenge handling, and edge absorption — plus protecting the origin IP so traffic cannot bypass the WAF.
Sources and verification
Verified facts: DDoS attacks have evolved to the Layer 7 application layer; network firewalls make decisions at OSI Layers 3 and 4; web traffic uses port 80 (HTTP); SSH uses port 22; a hash-collision-style attack can drive parser CPU to 100% with a few thousand requests; cache-bypass attacks multiply origin cost per request by up to 10,000x — all from WAFNinja published guides (wafninja.com), verified 2026-08-04. Mitigation effectiveness figures and switch-over times are marked pending verification because they depend on vendor, plan, and architecture.
