Firewall Rules FAQ

​​ How many rules can I have on my site?

You can create a large number of rules. However, the number of active rules at any given time is limited. Refer to Entitlements for details on what is allowed per customer plan.

​​ Can I purchase additional active rules?

No. The number of active rules is fixed based on customer plan. Refer to Entitlements .

​​ How are certain special and escaped characters handled?

When used as literals in an expression, the backslash \ and double quote " characters require proper escaping.

An expression built using the Visual Expression Editor does not require you to manually escape those special characters. Conveniently, the Expression Builder takes care of any necessary escaping in the final expression by automatically prepending a backslash such that \ and " become \\ and \", respectively.

The following image illustrates how double quotes are automatically escaped to \" once they appear in the plain text expression generated in the Expression Editor:

​​ Why isn’t my regular expression pattern matching working?

If you are using a regular expression, we recommend you test it against a testing tool like Regular Expressions 101 Open external link or Rustexp Open external link .

Also, note that http.request.method fields requires all-caps for method names.

​​ How can I use the Threat Score effectively?

The Cloudflare Threat Score is a key item behind the Security Level functionality in the Cloudflare dashboard.

Threat Score as configured by Security Level is based on:

• High - for scores greater than 0
• Medium - for scores greater than 14
• Low - for scores greater than 24
• Essentially off - for scores greater than 49

Enabling a high threat score for sensitive areas, like comment form pages or login forms, can add an effective level of protection. Integrating Threat Score with firewall rules is advantageous because you can specify a CAPTCHA vs. a JS Challenge, or even a block. You can also exclude IP addresses using and not logic.

​​ How does Firewall Rules handle traffic from known bots?

​​ Caution about potentially blocking bots

When you create a firewall rule with a Block, Legacy CAPTCHA, JS Challenge, or Managed Challenge (Recommended) action, you might unintentionally block traffic from known bots. Specifically, this might affect search engine optimization (SEO) and website monitoring when trying to enforce a mitigation action based on URI, path, host, ASN, or country.

Refer to How do I create an exception to exclude certain requests from being blocked or challenged? .

​​ Bots currently detected

The table below lists a sample of known bots that Cloudflare Firewall Rules currently detects. When traffic comes from these bots and others not listed, the cf.client.bot field is set to true.

​​ How do I create an exception to exclude certain requests from being blocked or challenged?

There may be situations in which you want to enforce a blocking or challenging action but make exceptions for specific types of requests.

Cloudflare supports two methods to permit requests through firewall rules expressions:

1. Exclude a type of request from being blocked or challenged, for example based on IP address, ASN, or country
2. Create an independent firewall rule with an Allow action

If you wish to permit certain exclusions, the examples below illustrate a few possible approaches.

​​ Example 1

Exclude multiple IP addresses from a blocking/challenging rule that assesses Threat Score

​​ Example 2

Block Amazon Web Services (AWS) and Google Cloud Platform (GCP) because of large volumes of undesired traffic, but allow Googlebot and other known bots that Cloudflare validates

​​ Why does a Firewall Event display a Cloudflare IP address even though other fields match the client details?

This happens when a request goes through a Cloudflare Worker.

In this case, Cloudflare considers the client details, including its IP address, for triggering security settings. However, the IP displayed in the Firewall Events will be a Cloudflare IP address.

​​ Do the Challenge actions support content types other than HTML (for example, AJAX or XHR requests)?

No. The Legacy CAPTCHA and JS Challenge actions only support HTML requests.

Challenges presented to users display an intermediate page where they must prove they are not a bot. This concept does not work over XHR or AJAX.

When an XHR or AJAX request triggers one of the Legacy CAPTCHA actions, the resulting request will have the following status code:

• HTTP status code 403 for Legacy CAPTCHA
• HTTP status code 503 for JS Challenge

Your application can use these status codes to handle unexpected challenges.

​​ Does the ‘challengeFailed’ action accurately represent challenges that users did not pass?

No. The challengeFailed and jschallengeFailed firewall rule actions account for observed requests that, under special circumstances, did not pass a challenge. However, some failed challenges cannot be traced back to a firewall rule. Additionally, Cloudflare Firewall Rules may not have a record of every request with a failed challenge.

Therefore, consider these actions with caution. A reliable indicator is the CSR (Challenge Solve Rate) displayed in Security > WAF > Firewall rules, which is calculated as follows: number of challenges solved / number of challenges issued.

​​ Why would I not find any failed challenges? Why is ‘ChallengeIssued’ not equal to ‘ChallengeSolved’ plus ‘ChallengeFailed’?

Users do not complete all challenges. Cloudflare issues challenges that are never answered — only 2-3% of all served challenges are usually answered.

There are multiple reasons for this:

• Users give up on a challenge.
• Users try to solve a challenge but cannot provide an answer.
• Users keep refreshing the challenge but never submit an answer.
• Users keep retrying hCaptcha (CAPTCHA failures in hCaptcha are not registered as failed and represent interim failures).
• Cloudflare receives a malformed challenge answer.

​​ Why do I have matches for a firewall rule that was not supposed to match the request?

Make sure you are looking at the correct request.

Only requests that triggered a challenge will match the request parameters of the rule. Subsequent requests with a [js]challengeSolved or [js]challengeFailed action may not match the parameters of the rule — for example, the bot score may have changed because the user solved a CAPTCHA.

The “solved” and “failed” actions are informative actions about a previous request that matched a rule. These actions state that “previously a rule had matched a request with the action set to Legacy CAPTCHA or JS Challenge and now that challenge was answered.”