WAF and DDoS
Apply managed rules, rate limits, caching, and origin controls without blocking normal users blindly.
Cloudflare’s edge can filter malicious HTTP requests and absorb attack traffic before it reaches the application. Effective protection still depends on knowing normal traffic, preventing origin bypass, and giving responders useful signals.
Layer the controls
| Layer | Primary job | Useful signal |
|---|---|---|
| DDoS managed rules | Detect and mitigate network or HTTP flood patterns | Mitigated traffic, protocol, rate, origin health |
| Managed WAF rules | Detect common exploit patterns | Rule, path, action, false-positive rate |
| Custom rules | Express application-specific allow or block policy | Match count and business impact |
| Rate limiting | Bound repeated use of selected endpoints | Requests per key, action, affected users |
| Cache | Serve repeatable content without reaching the origin | Hit ratio, origin requests, stale behavior |
| Origin restriction | Stop traffic that bypasses Cloudflare | Direct connection attempts |
Deploy managed rules deliberately
- Inventory frameworks, APIs, upload paths, authentication routes, and expected automation.
- Enable the Cloudflare managed ruleset with its recommended defaults for the applicable plan.
- Review Security Events and application errors during a representative traffic window.
- Tune by rule, tag, path, or verified client when a legitimate request is affected.
- Give every exception an owner, reason, narrow scope, and review date.
Do not enable every disabled rule without testing. Cloudflare notes that some rules are disabled to balance coverage and false positives. Likewise, do not create a broad skip rule to make one request work.
Rate-limit behavior, not the whole site
Start with endpoints where repeated requests have a clear cost or abuse pattern:
- login, password reset, and verification;
- expensive search or report generation;
- uploads and data exports;
- API routes with per-client quotas; and
- cache-bypass paths that reach costly dependencies.
Choose the counting key and threshold from observed traffic. Test the response your client receives, including 429 handling and retry behavior. A single IP can represent a shared corporate network, while an attacker may distribute requests across many IPs.
Prepare for DDoS before the alert
- Keep DDoS managed rules at the recommended sensitivity and mitigation action unless a reviewed exception requires otherwise.
- Restrict the origin to Cloudflare or use Tunnel.
- Cache safe content and prevent randomized query strings from defeating the intended cache policy.
- Bound origin connection, request, and application timeouts.
- Define which features can be degraded or temporarily disabled.
- Alert on edge traffic, mitigations, origin saturation,
5xxresponses, queue depth, and user-visible availability. - Record the provider escalation path and practice it.
Cloudflare automatically mitigates large attacks, but attacks can still affect an application through origin exposure, expensive dynamic paths, dependencies, or rules that do not match the application’s behavior.
Incident workflow
- Confirm whether the constrained resource is the edge, origin network, application, or dependency.
- Compare edge request volume with origin request volume and user-visible health.
- Identify the paths, methods, source distribution, cache status, and response codes driving impact.
- Apply the narrowest effective managed, custom, rate, or cache control.
- Watch legitimate success rates while mitigation is active.
- Preserve event data and document every temporary rule.
- Remove or convert emergency rules after review; do not leave unexplained blocks in place.