HTTP DDoS Protection Gets User-Configurable Managed Rules

Cloudflare has released the HTTP DDoS Managed Ruleset, giving customers on all plans—from Free to Enterprise—the ability to adjust their HTTP DDoS protection settings directly from the dashboard or via API. Previously, such customizations required going through support channels, which could delay resolution times.

The company's broader goal remains zero-touch protection: automated detection and mitigation systems that require no customer intervention. Most zones will not need any configuration changes. The new controls exist for the rare cases where traffic patterns or application behavior warrant adjustments, with future plans to make the rules self-tuning based on individual traffic profiles.

How the Autonomous System Works

The configurability rides on top of an existing autonomous mitigation stack. Cloudflare's network routes traffic via BGP Anycast to the nearest edge data center, where the home-grown L4 load balancer, Unimog, distributes it to the least-loaded servers. Each server independently scans for malicious traffic and applies mitigations locally, sharing intelligence with other servers via multicast. This decentralized model is what allows the company to offer unmetered DDoS protection—attack traffic is automatically excluded from billing without requiring service credit requests.

How to customize your HTTP DDoS protection settings

The system relies on dynamic rules that detect known attack tools, protocol violations, suspicious patterns, origin error spikes, and unusual traffic volumes. Each rule carries a predefined sensitivity level and default action, determined by the confidence that matched traffic is genuinely malicious. High-confidence matches for known attack tool patterns can be safely blocked, while ambiguous anomalies—which might stem from faulty applications or ill-behaved API clients—are better handled with softer responses like rate limiting or challenges.

What You Can Configure

Configuration happens under Firewall > DDoS in the dashboard. Customers who previously requested support-side customizations will find their zone set to Essentially off or Low sensitivity, and those settings are now visible and adjustable. Some exclusions or bypasses for specific HTTP attributes or IPs, and thresholds requiring Cloudflare approval, remain active but may not yet appear in the dashboard.

Two levels of control are available. At the ruleset level, you can change the Action and Sensitivity Level for all rules as a group:

BLOG-527 Embedded Image - ckFoXE

Alternatively, clicking Browse Rules allows per-rule overrides, which take priority over ruleset-level settings.

Mitigation Actions

The action dictates the response when a rule triggers. Rules with lower confidence typically default to a Challenge (CAPTCHA), while higher-confidence rules apply Block. The available actions are:

  • Block
  • Challenge (CAPTCHA)
  • Log
  • Use Rule Defaults

Two scenarios illustrate when changing actions makes sense. During onboarding of a new application with unusual or spiky traffic, setting the action to Log lets you observe what the system flags before enabling stricter measures. Conversely, if a detected attack is only being challenged or rate-limited by default logic and you are confident it is malicious, switching to Block provides complete mitigation.

Sensitivity Levels

Sensitivity defines how quickly a mitigation kicks in based on request-per-second thresholds. Available levels are:

  1. High (default)
  2. Medium
  3. Low
  4. Essentially Off

Essentially Off sets an exceptionally low sensitivity, meaning traffic is generally not mitigated. However, traffic at attack-like levels is still blocked to protect the stability of the Cloudflare network itself.

Lowering sensitivity may be appropriate when legitimate traffic is caught by a rule due to suspicious-looking patterns, or when a legacy application or a buggy API client generates protocol-violating requests that trigger false positives. In such cases, Essentially Off can serve as a stopgap while the underlying issue is fixed.

BLOG-527 Embedded Image - D6HTfN

Some rules show a DDoS Dynamic action. These use a multi-staged mitigation approach that selects from different actions based on attack type, request characteristics, and other factors. This dynamic behavior can also be overridden.

Viewing Attack Intelligence

When an attack is detected and mitigated, real-time DDoS alerts and details appear in the Firewall analytics dashboard. The triggered rule ID is recorded in the Activity log alongside each mitigated HTTP request log, providing visibility into which rules are firing.

BLOG-527 Embedded Image - 0CzFC4

Managed Rules Access

The configuration interface is available directly at the DDoS tab in the dashboard, and programmatic access is documented in the API reference.

BLOG-527 Embedded Image - MykZdH