DDoS Mitigation and Edge Security: What Cloudflare Actually Stops

Cloudflare's own H1 2026 DDoS Threat Report recorded 805 network-layer attacks exceeding 1 Tbps mitigated in a single quarter, a scale that makes clear why DDoS mitigation and edge security aren't optional hardening for anything with real internet exposure, but a baseline requirement. What's less obvious is which traffic actually gets stopped at the edge, and which patterns are specifically designed to look legitimate enough to get through anyway.

What edge security stops

A WAF, rate limiting, and network-layer DDoS mitigation sitting in front of an origin server handle three genuinely different problems. The WAF inspects request content, SQL injection payloads, known exploit patterns, malformed requests, and blocks what looks malicious regardless of volume. Rate limiting caps how often a single client (by IP, session, or fingerprint) can hit a given endpoint, stopping brute-force and scraping patterns that are individually well-formed but abusive in aggregate. Network-layer DDoS mitigation operates below both of those, absorbing sheer volumetric traffic (a UDP flood, an amplification attack) before it ever reaches an application server capable of inspecting it. Cloudflare's own scale here is real and specific: 500+ Tbps of network capacity across a global edge network is what makes absorbing an attack the size of the ones in that threat report possible without the origin ever seeing the traffic at all.

The traffic that gets through anyway

Volumetric floods are the attacks edge mitigation is best at, they're loud, they're obviously anomalous, and stopping them is a capacity problem the edge is built to win. What's genuinely harder is low-and-slow, application-layer abuse designed to look like normal user traffic: a credential-stuffing run distributed across thousands of residential proxy IPs (see our piece on credential stuffing and password reuse for why this specifically defeats naive rate limiting), a scraper mimicking real browser behavior closely enough to avoid bot-detection heuristics, or a business-logic abuse pattern, repeatedly hitting a "check discount code" endpoint to brute-force valid codes, that never trips a volumetric threshold because it was never high-volume to begin with. None of this looks like a DDoS attack to a system built to detect one; it looks like unusually persistent legitimate use.

Why edge security is a layer, not a replacement

None of the above replaces application-layer security, it reduces what reaches the application in the first place, buying real headroom, not a guarantee. A WAF with well-tuned rules stops known injection patterns; it doesn't understand your application's actual authorization logic, which is exactly why broken access control and IDOR findings routinely show up in applications sitting behind a fully configured WAF. Edge mitigation and application security are complementary layers, not substitutes for each other.

What needs configuring, not just enabling

• WAF rules tuned to the specific application, not left on default managed rulesets alone, a generic ruleset catches generic attacks, and misses anything specific to how your application actually behaves
• Rate limiting scoped per-endpoint, since a login page and a public content page have completely different legitimate traffic patterns and need different thresholds
• Bot-detection heuristics reviewed periodically, since scraping and credential-stuffing tooling actively evolves specifically to blend into what "normal" traffic looks like to whatever detection is currently deployed
• DNSSEC and origin-IP protection, so an attacker can't simply bypass the edge entirely by finding and hitting the origin server's real IP directly

Configuring this correctly, not just turning Cloudflare on with default settings, is exactly the scope of our Cloudflare Security engagements, alongside the broader Network Security Testing work that validates what actually reaches an origin server versus what's stopped at the edge.