Skip to content
Firewall
Visit Firewall on GitHub
Set theme to dark (⇧+D)

Frequently asked questions (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. See 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. See 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 in the Firewall Rules UI 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:

Escaped characters

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 or Rustexp.

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, Challenge (Captcha), or JS Challenge 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.

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

Bots currently detected

The table below lists known bots that Firewall Rules currently detects. When traffic comes from any of these bots, the cf.client.bot field is set to true.

BotDescription

ahrefs

Ahrefs SEO bot

apple

Applebot is the web crawler for Apple, for products like Siri and Spotlight Suggestions

archive.org

Archive.org bots

baidu

Baidu search engine bots

better uptime

Bot for monitoring website uptime

bing

Bing search engine bots

feedbin

Feedbin.com bots

google

Google search engine bots

grapeshot

Grapeshot (Oracle) SEO bots

linkedin

LinkedIn bots

mail.ru

Mail.ru bots

naver

Naver (South Korean) search engine bots

pingdom

Pingdom.com monitoring bots

pinterest

Pinterest bots

seznam

Seznam search engine bots

sogou

Sogou search engine bots

uptimerobot

Uptime Robot monitoring bots

yahoo

Yahoo! search engine bots

yandex

Yandex search engine bots

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

Basic rule, with no exclusion
Actionblock (or challenge)
Expression(http.host eq "example.com" and cf.threat_score > 5)
Rule that excludes IP addresses from being blocked/challenged
Actionblock (or challenge)
Expression(http.host eq "example.com" and cf.threat_score > 5) and not (ip.src in {1.2.3.4 4.3.2.110.20.30.0/24})
Two rules to allow exceptions and block the rest
Rule 1Action: allow
Expression: ip.src in {1.2.3.4 4.3.2.110.20.30.0/24}
Rule 2Action: block (or challenge)
(http.host eq "example.com" and cf.threat_score > 5)

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

Basic rule, with no exclusion
Actionblock (or challenge)
Expression(ip.geoip.asnum in {7224 15169})
Rule that excludes known bots that Cloudflare validates
Actionblock (or challenge)
Expression(ip.geoip.asnum in {7224 15169}) and not cf.client.bot)
Two rules to allow exceptions and block the rest
Rule 1Action: allow
Expression: cf.client.bot
Rule 2Action: block (or challenge)
Expression: (ip.geoip.asnum in {7224 15169})

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 Challenge (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 Challenge actions, the resulting request will have the following status code:

  • HTTP status code 403 for Challenge (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 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, the Firewall 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 Firewall Rules, which is calculated as follows: number of challenges solved / number of challenges issued.

Why would I not see 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 see 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 Challenge (Captcha) or JS Challenge and now that challenge was answered".