Challenge bad bots

Cloudflare's Bot Management feature scores the likelihood that a request originates from a bot.

Before creating custom rules for bot protection, review the settings on your Security Settings page under Bot traffic. Built-in features auto-update with new bot signatures, do not count toward your custom rule limits, and are simpler to manage.

Custom rules are still valuable when you need path-specific protection (different handling for /api/ vs. /login/), custom score thresholds (for example, score below 20 instead of 30), conditional logic combining bot score with other fields, or custom actions not available in the built-in settings.

Bot score ranges from 1 through 99. A low score indicates the request comes from a script, API service, or an automated agent. A high score indicates that a human issued the request from a standard desktop or mobile web browser.

These examples use:

• cf.bot_management.score to target requests from bots
• cf.bot_management.verified_bot to identify requests from known good bots
• cf.bot_management.ja3_hash to target specific JA3 Fingerprints

For best results:

• Use Bot Analytics to learn about your traffic before applying rules.
• Start small and increase your bot threshold over time.

Your rules may also vary based on the nature of your site and your tolerance for false positives.

The following three custom rules provide baseline protection against malicious bots:

Rule 1: Skip verified bots

• Expression: (cf.bot_management.verified_bot)
• Action: Skip:
  • All remaining custom rules
• Known good bots (Googlebot, Bingbot, monitoring services) bypass all custom rules. Refer to the verified bots list and Radar bots directory .

Rule 2: Block definitely automated

• Expression: (cf.bot_management.score eq 1)
• Action: Block
• Score 1 traffic is definitively automated. Blocking it carries minimal false positive risk.

Rule 3: Challenge likely automated

• Expression: (cf.bot_management.score gt 1 and cf.bot_management.score lt 30)
• Action: Managed Challenge
• Scores 2-29 indicate likely automated behavior. A challenge lets legitimate users through while stopping bots.

When a request is definitely automated (score of 1) or likely automated (scores 2 through 29) and is not on the list of known good bots, Cloudflare blocks the request.

• Expression: (cf.bot_management.score lt 30 and not cf.bot_management.verified_bot)
• Action: Block

Since Bot Management detects automated users, you need to explicitly allow your good automated traffic this includes your APIs and partner APIs.

This example offers the same protection as the browser-only rule, but allows automated traffic to your API.

• Expression: (cf.bot_management.score lt 30 and not cf.bot_management.verified_bot and not starts_with(http.request.uri.path, "/api"))
• Action: Block

Since Bot Management can be more sensitive to mobile traffic, you may want to add in additional logic to avoid blocking legitimate requests.

If you are handling requests from your own mobile application, you could potentially allow it based on its specific JA3 fingerprint.

• Expression: (cf.bot_management.ja3_hash eq "df669e7ea913f1ac0c0cce9a201a2ec1")
• Action: Skip:
  • All remaining custom rules

Otherwise, you could set lower thresholds for mobile traffic. The following rules would block definitely automated mobile traffic and challenge likely automated traffic.

Rule 1:

• Expression: (cf.bot_management.score lt 2 and http.user_agent contains "App_Name 2.0")
• Action: Block

Rule 2:

• Expression: (cf.bot_management.score lt 30 and http.user_agent contains "App_Name 2.0")
• Action: Managed Challenge

If your domain handles mobile, browser, and API traffic, you would want to arrange these example rules in the following order:

• Rule for API traffic
• Rule(s) for mobile traffic
• Rule for browser traffic

Static resources are protected by default when you create custom rules using the cf.bot_management.score field.

To exclude static resources, include not (cf.bot_management.static_resource) in your rule expression. For details, refer to Static resource protection.

From there, you could customize your custom rules based on specific request paths (/login or /signup), common traffic patterns, or many other characteristics.

Make sure you review Bot Analytics and Security Events to check if your rules need more tuning.

• Use case: Allow traffic from verified bots
• Tutorial: Integrate Turnstile, WAF, and Bot Management