Troubleshoot managed rules

By default, WAF's managed rulesets are compatible with most websites and web applications. However, false positives and false negatives may occur:

• False positives: Legitimate requests detected and mitigated as malicious.
• False negatives: Malicious requests that were not mitigated and reached your origin server.

You can use Security Events to help you identify what caused legitimate requests to get blocked. Add filters and adjust the report duration as needed.

If you encounter a false positive caused by a managed rule, do one of the following:

• Add an exception: Exceptions allow you to skip the execution of WAF managed rulesets or some of their rules for certain requests.

• Adjust the OWASP managed ruleset: A request blocked by the rule with ID ...843b323c and description 949110: Inbound Anomaly Score Exceeded refers to the Cloudflare OWASP Core Ruleset. To resolve the issue, configure the OWASP managed ruleset.

• Disable the corresponding managed rule(s): Create an override to disable specific rules. This may avoid false positives, but you will also reduce the overall site security. Refer to the dashboard instructions on configuring a managed ruleset, or to the API instructions on creating an override.

• If one specific rule causes false positives, disable that specific rule and not the entire ruleset.

• For false positives with the administrator area of your website, add an exception disabling a managed rule for the admin section of your site resources. You can use an expression similar to the following:

  http.host eq "example.com" and starts_with(http.request.uri.path, "/admin")

To identify false negatives, review the HTTP logs on your origin server.

To reduce false negatives, use the following checklist:

• Are DNS records that serve HTTP traffic proxied through Cloudflare?
  Cloudflare only mitigates requests in proxied traffic.

• Have you deployed any of the WAF managed rulesets in your zone?
  You must deploy a managed ruleset to apply its rules.

• Are Managed Rules being skipped via an exception?
  Use Security Events to search for requests being skipped. If necessary, adjust the exception expression so that it matches the attack traffic that should have been blocked.

• Have you enabled any necessary managed rules that are not enabled by default?
  Not all rules of WAF managed rulesets are enabled by default, so you should review individual managed rules.

  • For example, Cloudflare allows requests with empty user agents by default. To block requests with an empty user agent, enable the rule with ID ...0a6dbbd3 in the Cloudflare Managed Ruleset.
  • Another example: If you want to block unmitigated SQL injection (SQLi) attacks, make sure the relevant managed rules tagged with sqli are enabled in the Cloudflare Managed Ruleset.

  For instructions, refer to Configure a managed ruleset.

• Is the attack traffic matching a custom rule skipping all Managed Rules?
  If necessary, adjust the custom rule expression so that it does not apply to the attack traffic.

• Is the attack traffic matching an allowed ASN, IP range, or IP address in IP Access rules?
  Review your IP Access rules and make sure that any allow rules do not match the attack traffic.

• Is the malicious traffic reaching your origin IP addresses directly, therefore bypassing Cloudflare protection?
  Block all traffic except from Cloudflare's IP addresses at your origin server.

If WAF's managed rulesets do not detect a specific attack pattern after verifying the above, consider the following:

• Use WAF attack score to complement signature-based managed rules with machine-learning detection. Attack score classifies each request with a score indicating the likelihood it is malicious, even when no managed rule matches.

• Create a custom rule to block the specific attack pattern. Use fields such as URI path, query string, or HTTP request headers to match the malicious requests.