FAQ
Why does a security 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 Security Events will be a Cloudflare IP address.
Yes, you may have to escape certain characters in expressions. The exact escaping will depend on the string syntax you use:
- If you use the raw string syntax (for example,
r#"this is a string"#), you will only need to escape characters that have a special meaning in regular expressions. - If you use the quoted string syntax (for example,
"this is a string"), you need to perform additional escaping, such as escaping special characters"and\using\"and\\, both in literal strings and in regular expressions.
For more information on string syntaxes and escaping, refer to String values and regular expressions.
If you are using a regular expression, it is recommended that you test it with a tool such as Regular Expressions 101 ↗ or Rustexp ↗.
In certain situations you want to enforce a blocking or challenging action but make an exception for specific types of requests.
Cloudflare supports two methods of allowing requests using WAF custom rules:
- Exclude a type of request from being blocked or challenged in a custom rule by updating the rule expression, for example adding an exclusion based on IP address, ASN, or country.
- Create a separate custom rule with a Skip action. This skip rule must appear before the rule with the block/challenge action in the rules list.
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, no exclusion:
- Expression:
(http.host eq "example.com" and cf.threat_score > 5) - Action: Block (or a challenge action)
- Expression:
-
Rule that excludes IP addresses from being blocked/challenged:
- Expression:
(http.host eq "example.com" and cf.threat_score > 5) and not (ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24}) - Action: Block (or a challenge action)
- Expression:
-
Two rules to skip remaining custom rules for specific IPs and block the rest.
- Rule 1:
- Expression:
ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24} - Action: Skip > All remaining custom rules
- Rule 2:
- Expression:
(http.host eq "example.com" and cf.threat_score > 5) - Action: Block (or a challenge action)
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, no exclusion:
- Expression:
(ip.geoip.asnum in {16509 15169}) - Action: Block (or a challenge action)
- Expression:
-
Rule that excludes IP addresses from being blocked/challenged:
- Expression:
(http.host eq "example.com" and cf.threat_score > 5) and not (ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24}) - Action: Block (or a challenge action)
- Expression:
-
Two rules to skip remaining custom rules for specific IPs and block the rest.
- Rule 1:
- Expression:
ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24} - Action: Skip > All remaining custom rules
- Rule 2:
- Expression:
(http.host eq "example.com" and cf.threat_score > 5) - Action: Block (or a challenge action)
If you have SSL/TLS certificates managed by Cloudflare, every time a certificate is issued or renewed, a domain control validation (DCV) must happen. When a certificate is in pending_validation state and there are valid DCV tokens in place, some Cloudflare security features such as custom rules and WAF Managed Rules will be automatically disabled on specific DCV paths (for example, /.well-known/pki-validation/ and /.well-known/acme-challenge/).
When you create a WAF custom rule with a Block, Interactive Challenge, 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 exclude certain requests from being blocked or challenged?.
Cloudflare Radar ↗ lists a sample of known bots that the WAF currently detects. When traffic comes from these bots and others not listed, the cf.client.bot field is set to true.
To submit a friendly bot to be verified, go to the Verified bots ↗ page in Cloudflare Radar and select Add a bot.
For more information on verified bots, refer to Bots.
Previously, unless you customize your front-end application, any AJAX request that is challenged will fail because AJAX calls are not rendered in the DOM.
Now, you can opt-in to Turnstile’s Pre-Clearance cookies. This allows you to issue a challenge early in your web application flow and pre-clear users to interact with sensitive APIs. Clearance cookies issued by a Turnstile widget are automatically applied to the Cloudflare zone that the Turnstile widget is embedded on, with no configuration necessary. The duration of the clearance cookie’s validity is controlled by the zone-specific configurable Challenge Passage security setting.
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 Challenge Solve Rate (CSR) 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.
- Cloudflare receives a malformed challenge answer.
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 challenge.
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 Interactive Challenge or JS Challenge and now that challenge was answered.”