Skip to content

Stop malicious bots while allowing legitimate traffic (Free, Pro, and Business)

The right defense against malicious bot traffic depends on the traffic patterns on your site and your plan. This guide covers a layered approach using Cloudflare Bots, Cloudflare Application Security (also known as Web Application Firewall or WAF), and Turnstile, from baseline protection to targeted custom rules. The core workflow uses features on Free, Pro, and Business plans, with callouts for Enterprise options. Most settings in this guide are configured per domain. Select a domain in the Cloudflare dashboard before following the steps below.

Review your bot traffic

Before you change any bot settings, review your traffic data to understand what bots are doing on your site.

Find your bot analytics

Bot analytics show you how much of your traffic is automated, which pages bots target, and how Cloudflare scores each request.

  1. In the Cloudflare dashboard, go to the Analytics page.

    Go to Analytics
  2. Select the Bot analysis tab.

Review the following:

  • Bot score distribution chart: Scores closer to 1 indicate automated traffic. Scores closer to 99 indicate human traffic.
  • Top requested paths: Which endpoints receive the most bot traffic. Login pages, API endpoints, and checkout flows are common targets.
  • Traffic patterns: Sudden spikes in low-score traffic, specific user agents appearing at high volume, or geographic concentration of requests can indicate bot activity worth investigating.

Understand bot categories

Cloudflare classifies bot traffic into categories based on bot scores and verification status:

  • Verified bots: Crawlers and services that Cloudflare has confirmed as legitimate, such as Googlebot, Bingbot, and uptime monitors. Cloudflare maintains a verified bot list with strict requirements.
  • Automated (score 1): Cloudflare is quite certain the request is automated.
  • Likely automated (scores 2-29): Probably a bot. This category and Automated are your primary targets, including scrapers, credential stuffing tools, and spam submitters.
  • Likely human (scores 30-99): These requests appear to come from real users. Do not challenge or block this traffic.

Block automated traffic with Bot Fight Mode

Bot Fight Mode identifies requests that match known bot patterns and issues a computational challenge. It reduces automated traffic across your entire site without requiring you to write any rules.

What Bot Fight Mode does

Bot Fight Mode is included with Free plans. When enabled, it:

  • Identifies traffic matching patterns of known bots
  • Issues computationally expensive challenges in response to these bots
  • Protects entire domains without endpoint restrictions
  • Cannot be customized, adjusted, or reconfigured via custom rules
  • Cannot be bypassed with custom rule Skip actions. If Bot Fight Mode challenges a request you want to allow, you can turn off Bot Fight Mode or upgrade to Super Bot Fight Mode for more granular control.

For more details, refer to Bot Fight Mode considerations.

Turn on Bot Fight Mode (Free plan)

  1. In the Cloudflare dashboard, go to the Security Settings page.

    Go to Settings
  2. Filter by Bot traffic.

  3. Go to Bot fight mode.

  4. Turn Bot fight mode on.

Enable Super Bot Fight Mode (Pro, Business, and Enterprise)

Super Bot Fight Mode adds verified bot allowlisting, per-category actions, static resource protection, and JavaScript detections. If Bot Fight Mode is currently active on your domain, disable it before enabling Super Bot Fight Mode.

For full details and setup instructions, refer to Super Bot Fight Mode.

Protect forms from automated abuse

Turnstile and Application Security rate limiting rules protect form endpoints in different ways and work best together.

Turnstile versus rate limiting

Turnstile challenges suspected bots before they can submit a form (login, signup, contact, or checkout), without showing visitors a CAPTCHA. It can be embedded into any website without sending traffic through Cloudflare. Use Turnstile when you need to challenge automated form submissions.

Rate limiting allows you to define rate limits for requests matching an expression and the action to perform when those limits are reached. Use rate limiting to protect endpoints from abuse, such as brute-force attacks on a login page or excessive API calls from a single client.

Both together provide the strongest coverage. Turnstile challenges automated submissions at the form level. Rate limiting catches high-volume attacks that bypass or do not encounter the form, such as direct POST requests to the endpoint that skip the client-side widget.

Add Turnstile to a form

Adding Turnstile involves three steps: create a widget, add the client-side snippet, and validate the token on your server.

1. Create a Turnstile widget

Turnstile is configured at the account level.

  1. In the Cloudflare dashboard, go to the Turnstile page.

    Go to Turnstile
  2. Select Add widget.

  3. Fill out the required information:

    • Widget name: A descriptive name for your widget.
    • Hostname management: Domains where the widget will be used.
    • Widget mode: Choose from Managed, Non-Interactive, or Invisible.
  4. (Optional) Configure Pre-clearance support for single-page applications.

  5. Select Create to save your widget.

  6. Copy your sitekey and secret key, and store the secret key securely.

You need both the sitekey and secret key in the following steps.

2. Add the client-side snippet

Add the Turnstile script and widget container to your form HTML:

<script
src="https://challenges.cloudflare.com/turnstile/v0/api.js"
async
defer
></script>
<form action="/submit" method="POST">
<!-- Your existing form fields -->
<div class="cf-turnstile" data-sitekey="<YOUR_SITE_KEY>"></div>
<button type="submit">Submit</button>
</form>

Replace <YOUR_SITE_KEY> with the sitekey from the previous step. The widget renders inside the div and produces a token when the visitor passes the challenge.

3. Validate the token on your server

Before processing the form submission, send the token to the Turnstile siteverify endpoint to confirm the visitor passed the challenge:

Terminal window
curl https://challenges.cloudflare.com/turnstile/v0/siteverify \
--header "Content-Type: application/json" \
--data '{
"secret": "<YOUR_SECRET_KEY>",
"response": "<TURNSTILE_RESPONSE_TOKEN>"
}'

Replace <YOUR_SECRET_KEY> with your secret key and <TURNSTILE_RESPONSE_TOKEN> with the cf-turnstile-response value from the form submission. The endpoint returns a JSON object with a success field. Only process the form submission if success is true.

For complete integration details, refer to Turnstile get started.

Limit request volume on form endpoints with rate limiting

For login endpoints, a tiered rate limiting approach works well alongside Turnstile. The following example from the Rate limiting best practices shows two rules that escalate the response based on the volume of failed attempts. Adjust the thresholds for your site's traffic patterns.

Short-window rule: Challenge an IP that sends too many failed login requests in a short window.

  1. In the Cloudflare dashboard, go to Security > Security rules.

    Go to Security rules
  2. Select Create rule > Custom rules.

  1. Select Create rule > Rate limiting rules.
  2. Enter a descriptive name in Rule name.
  3. Under If incoming requests match, select Edit expression and enter: http.request.uri.path eq "/login" and http.request.method eq "POST"
  4. Under With the same characteristics, select IP.
  5. Enable Use custom counting expression and enter: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
  6. Under When rate exceeds, enter 4 requests per 1 minute.
  7. Under Then take action, select Managed Challenge.
  8. Select Deploy.

Long-window rule: Block an IP that accumulates failed login attempts over a longer period.

  1. Select Create rule > Rate limiting rules.
  2. Enter a descriptive name in Rule name.
  3. Under If incoming requests match, select Edit expression and enter: http.request.uri.path eq "/login" and http.request.method eq "POST"
  4. Under With the same characteristics, select IP.
  5. Enable Use custom counting expression and enter: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
  6. Under When rate exceeds, enter 20 requests per 1 hour.
  7. Under Then take action, select Block with a duration of 1 day.
  8. Select Deploy.

This pattern uses a counting expression that only counts POST requests returning authentication failure codes. Legitimate users who log in successfully on the first attempt never trigger the rule. Review the results in Security Events to confirm the thresholds are not catching legitimate users.

For the full tiered credential stuffing example with three rules, refer to Rate limiting best practices.

Target bot patterns with custom rules and rate limiting

Application Security custom rules and rate limiting rules let you target specific traffic patterns that built-in bot protection does not catch. Cloudflare separates detection (scoring traffic) from mitigation (acting on those scores). You write rules that reference detection signals to decide what action to take.

Block requests with missing or suspicious headers

Legitimate browsers typically send headers like User-Agent, Accept, and Accept-Language. Many bots omit these headers or send non-browser values. A custom rule targeting requests with empty or suspicious headers catches bots that evade score-based detection.

Before creating custom rules, review the built-in bot settings in Security > Settings (filter by Bot traffic). These settings handle common scenarios like blocking AI crawlers, challenging automated traffic, and allowing verified bots without requiring you to write expressions. For the full list of built-in settings, refer to Challenge bad bots.

If the built-in settings do not cover your needs, create custom rules. Start by creating an exception for verified bots so they are protected before you deploy any blocking rules.

Navigate to custom rules, then create both rules:

  1. In the Cloudflare dashboard, go to Security > Security rules.

    Go to Security rules
  2. Select Create rule > Custom rules.

First, create a verified bot exception:

  1. Select Create rule.
  2. Enter a descriptive name in Rule name.
  3. Under When incoming requests match, select Edit expression and enter: (cf.client.bot)
  4. Under Then take action, select Skip from the Choose action dropdown. Then select All remaining custom rules.
  5. Under Place at, select First from the Select order dropdown so this rule executes before any blocking rules.
  6. Select Deploy.

This ensures verified bots (search engine crawlers, monitoring services) bypass your custom rules. If you have internal APIs, partner integrations, or monitoring tools that send automated traffic, create additional Skip rules for their IP addresses or user agents before deploying blocking rules. Review your expected automated traffic in Security Events to identify what to allowlist.

Then, create a blocking rule:

  1. Select Create rule.
  2. Enter a descriptive name in Rule name.
  3. Under When incoming requests match, select Edit expression and enter: (http.request.uri.path eq "/login" and http.request.method eq "POST")
  4. Under Then take action, select Managed Challenge from the Choose action dropdown.
  5. Under Place at, leave the Select order dropdown set to Last. This places the rule after the verified bot exception.
  6. Select Deploy.
  7. Review the results in Security Events. If the rule matches only bot traffic, edit the rule and change the action from Managed Challenge to Block.

For additional custom rule options including the visual field builder, refer to Create a custom rule in the dashboard.

If your bot traffic is concentrated from countries where you have no real users, you can combine geographic filters with the rules above. Add ip.src.country to your expression to restrict the rule to specific regions. For examples, refer to Block traffic by geographical location.

Protect high-frequency paths with rate limiting

Beyond form endpoints, bots also target checkout flows, API endpoints, and other high-value paths. Rate limiting rules cap the number of requests a single client can make to these paths within a time window.

The following example creates a rate limiting rule for a checkout endpoint. Adjust the path, rate, and action for your site.

  1. In the Cloudflare dashboard, go to Security > Security rules.

    Go to Security rules
  2. Select Create rule > Custom rules.

  1. Select Create rule > Rate limiting rules.
  2. Enter a descriptive name in Rule name.
  3. Under If incoming requests match, select Edit expression and enter: http.request.uri.path eq "/api/checkout" and http.request.method eq "POST"
  4. Under With the same characteristics, select IP.
  5. Under When rate exceeds, enter 10 requests per 1 minute.
  6. Under Then take action, select Managed Challenge.
  7. Select Deploy.
  8. Review the results in Security Events. If the rule matches only bot traffic, edit the rule and change the action to Block if needed.

For additional patterns and thresholds, refer to Rate limiting best practices.

Verify and tune your rules

After you deploy bot protection rules, use Security Events to verify they are working as intended and adjust thresholds based on the results.

Check Security Events

Security Events displays requests that Cloudflare security products acted on or flagged, including blocks, challenges, and flags.

  1. In the Cloudflare dashboard, go to the Analytics page.

    Go to Analytics
  2. Select the Events tab.

Review the Sampled logs to inspect individual requests. Each log entry shows the action taken, the rule that triggered, the source IP, user agent, URI path, and country. Available dashboard sections vary by plan. Refer to Security Events availability for your plan's features.

Look for false positives (legitimate traffic that your rules incorrectly challenged or blocked). Common signs include:

  • Requests from known monitoring services or payment processors appearing in blocked events
  • User agents matching legitimate browsers but receiving challenges
  • High volumes of challenged requests from countries where you have real users

For rules using the Managed Challenge action, check the challenge solve rate (CSR). A low CSR likely indicates the rule is effectively filtering automated traffic rather than legitimate users.

Bot Fight Mode and Super Bot Fight Mode are aggressive by design. False positives are expected, especially in the first few days after turning them on. The key difference between the two is how you handle exceptions:

  • Bot Fight Mode (Free) cannot be bypassed with custom rule Skip actions. You can turn off Bot Fight Mode or upgrade to Super Bot Fight Mode for more control.
  • Super Bot Fight Mode (Pro and above) can be bypassed with custom rules using the Skip action, giving you more flexibility to create exceptions.

For more information on handling false positives, refer to False positives.

Adjust your rules

After reviewing Security Events, adjust your rules based on the results.

Scenario 1: Your monitoring tools or services are being blocked.

Internal monitoring tools, health check services, or partner APIs appear in blocked events. The fix depends on which feature is blocking them:

  • If Super Bot Fight Mode (Pro and above) is blocking the traffic, create a custom rule with a Skip action matching the tool IP address or user agent:

    1. Go to the Security rules page.

      Go to Security rules
    2. Select Create rule > Custom rules.

    3. Enter a descriptive name.

    4. Under When incoming requests match, select Edit expression and enter: (ip.src eq 192.0.2.1) (replace with your tool's IP address).

    5. Under Then take action, select Skip. Then select All Super Bot Fight Mode rules.

    6. Select Deploy.

  • If Bot Fight Mode (Free) is blocking the traffic, turn off Bot Fight Mode or upgrade to Super Bot Fight Mode for granular exception rules.

For details on Skip action configuration, refer to Configure a rule with the Skip action.

Scenario 2: Malicious traffic is still getting through.

Bot activity appears in Security Events that your current rules do not catch. Bots that stay under rate limits or evade single-signal rules require combining multiple signals. For example, to challenge POST requests to /login that are not from verified bots:

  1. In the Cloudflare dashboard, go to Security > Security rules.

    Go to Security rules
  2. Select Create rule > Custom rules.

  1. Select Create rule.

  2. Enter a descriptive name.

  3. Under When incoming requests match, select Edit expression and enter:

    (http.request.uri.path eq "/login" and http.request.method eq "POST" and not cf.client.bot)
  4. Under Then take action, select Managed Challenge.

  5. Select Deploy.

  6. Review the results in Security Events. If the rule matches only bot traffic, change the action to Block.

For more expression fields and examples, refer to Custom rules use cases.

If bots are staying under your rate limiting thresholds, edit the rate limiting rule and reduce the request count or shorten the time window.

Bots

Application Security

Turnstile

  • Turnstile — Free, privacy-preserving challenge for forms and user interactions