Cloudflare Bot Management best practices: production tuning, fingerprinting and WAF rules

Deploying Bot Management is not the challenge. Tuning it in production is.

Roughly a third of all internet requests are automated, according to Cloudflare Radar. That share is broken down per zone in the dashboard, but the headline figure sets the stakes: a Bot Management configuration left at defaults is a configuration that is wrong on a third of your traffic.

Most Cloudflare Bot Management installations stop at the activation toggle. The dashboard turns green, a sensible default threshold is left in place, and the project closes. Six months later, the same organisation discovers three things at once: legitimate mobile traffic is being challenged, scrapers are still in the logs, and attackers have quietly moved to the endpoints nobody thought to monitor.

This guide is the configuration pass we run at Brixio, as an Authorized Cloudflare Service Delivery Partner (ASDP), on production deployments. It covers what the defaults do, where they fail, and how to tighten Bot Management without breaking real users. Every rule and field cited here corresponds to live Cloudflare documentation as of May 2026.

Why default Bot Management settings under-deliver

The default settings shipped with Bot Management are deliberately conservative. They protect entire domains with broad rules, optimised to avoid false positives at any cost. That is the right starting point for the day of activation. It is the wrong destination.

In production, three limits surface quickly:

1. Defaults treat all endpoints the same. A login page and a public marketing page run under identical thresholds. The login page is where credential-stuffing attempts happen. The marketing page does not need the same scrutiny.
2. Defaults expose only two coarse buckets. Bot Management produces a per-request score from 1 to 99, but the built-in settings only act on “definitely automated” (score 1) and “likely automated” (scores 2 to 29). The 70 % of traffic between 30 and 99 is treated as human. In practice, the interesting tuning lives in the 30 to 50 band.
3. Defaults do not combine signals. A score of 25 from a verified mobile-app fingerprint is not the same risk as a score of 25 from an unknown ASN in a region you do not serve. Bot settings do not let you express that distinction. Custom rules do.

Attackers know all of this. When a web funnel is hardened with Bot Management plus a Web Application Firewall (WAF), they pivot to the channels that were left at default. The mobile-app API is the most common landing zone, because client-side CAPTCHA challenges cannot run there.

Bot Management is only as effective as the custom rules layered on top of it.

The three Cloudflare bot products, plus Bot Shield

Cloudflare offers three native bot products. Brixio adds a fourth layer, Bot Shield, for the gap none of the three were built to cover.

• Bot Fight Mode (Free) — no per-request score, no custom rules, no JS Detections, no JA3/JA4, no detection IDs, no AI-bot controls.
• Super Bot Fight Mode (Pro, Business, Enterprise without add-on) — no score, custom rules limited to Skip action only, no JS Detections, no fingerprints, no detection IDs, partial AI-bot controls.
• Bot Management for Enterprise (add-on) — full 1-99 score, full custom rules, JS Detections, JA3/JA4 fingerprints, detection IDs, full AI-bot controls.
• Bot Shield by Brixio (add-on layer) — custom signals, custom rules, JA3/JA4 fingerprint reputation.

Bot Fight Mode and Super Bot Fight Mode share the same underlying detection engine as Bot Management Enterprise, but expose only domain-wide toggles. They are useful for small sites. They are not enough for ecommerce, banking, payments, or any application where the cost of a missed bot exceeds the cost of an Enterprise add-on.

For granular control, per-request scoring, and the ability to write rules against specific endpoints, only Bot Management for Enterprise will do. Contact your Cloudflare account team to enable it on the zone. See the official plan comparison for the full feature matrix.

Bot Shield by Brixio sits one layer above. It is a proprietary detection product we developed at Brixio, designed to complement Cloudflare Bot Management, WAF, API Shield, and Turnstile. It targets the channels where Cloudflare's defaults are blind by design: native mobile APIs, where CAPTCHA cannot run and where attackers concentrate their effort once the web channel is locked down. Bot Shield uses JA3/JA4 fingerprint reputation as its core signal, deploys in LOG mode for observation before any enforcement, and ships with a per-route dashboard. We use it on production zones where Cloudflare Bot Management alone leaves residual exposure. A real deployment is described later in this article.

What does the Cloudflare bot score mean?

Cloudflare assigns every request a cf.bot_management.score from 1 to 99. A score of 1 is definitely automated. A score of 99 is human-like. The interesting tuning happens between 30 and 50.

Every request that reaches a zone with Bot Management enabled is scored on the field cf.bot_management.score, an integer between 1 and 99. A low score means more automated behaviour. A high score means more human-like behaviour.

Cloudflare publishes two official groupings:

• Score 1: definitely automated. The certainty is high enough that blocking carries almost no false-positive risk.
• Scores 2 to 29: likely automated. The right action is usually Managed Challenge, which lets a human behind a virtual private network or Tor pass while stopping headless browsers.
• Scores 30 to 99: treated as human by default. In practice, the tuning band sits between 30 and 50.

The 30 cutoff is a starting point, not a universal rule. A login endpoint may justify a stricter threshold of 40. A search endpoint serving anonymous traffic may live happily at 20. The right approach is to deploy rules in Log action first, observe for seven to fourteen days, then move to Block or Managed Challenge. The Cloudflare documentation makes the same recommendation: start small and increase your bot threshold over time.

Which three baseline custom rules should every production zone have?

In order: skip verified bots, block score 1, and challenge scores 2 to 29. Everything else is per-endpoint tuning on top of that baseline.

Every Bot Management deployment Brixio operates uses the same three baseline rules, in this order. They are derived from Cloudflare's own published guidance and refined from production experience.

Rule 1: Skip verified bots

Expression: (cf.bot_management.verified_bot)
Action:     Skip → All remaining custom rules

Verified bots are the allowlist Cloudflare maintains for Googlebot, Bingbot, Pingdom, Datadog, monitoring agents, and other beneficial automation. Skipping them prevents the rest of the rule set from challenging traffic you actually want.

The trap to know about: not every legitimate internal scanner is a verified bot. A continuous-integration job hitting a staging environment, a vulnerability scanner mandated by a Payment Card Industry (PCI) audit, or a partner integration polling an inventory feed will all look like bots and score accordingly. Whitelist them explicitly by IP range or JA3/JA4 fingerprint before they hit Rule 2.

Rule 2: Block definitely automated

Expression: (cf.bot_management.score eq 1)
Action:     Block

Score 1 is the cleanest bucket in Bot Management. The certainty is high enough that a hard block is the right action. False-positive risk on this rule, in our production experience, is below 0.05 %.

Rule 3: Challenge likely automated

Expression: (cf.bot_management.score gt 1 and cf.bot_management.score lt 30)
Action:     Managed Challenge

Managed Challenge is preferable to Block on this band because the population includes a long tail of real humans behind privacy proxies, residential virtual private networks, and shared exit nodes. Cloudflare's Managed Challenge issues a non-interactive verification first and falls back to an interactive one only when needed.

Together, those three rules give you a baseline that stops obvious automation while preserving good traffic. Everything that follows is tuning.

How do you tune Bot Management per endpoint?

Four channel types deserve different thresholds: browser pages, APIs, login endpoints, and mobile-app traffic. The same bot score is read differently in each.

Domain-wide bot rules are a starting point. The real work is per-endpoint tuning. Brixio's standard pass covers four channel types.

Browser endpoints

For traffic served as HTML pages, enable JavaScript Detections. Cloudflare injects an invisible JavaScript snippet that issues a cf_clearance cookie after verification. The result is exposed in the field cf.bot_management.js_detection.passed. Add a custom rule that challenges or blocks requests where this field is false. Combine with the baseline rules above.

API endpoints

APIs should not rely on bot scoring alone. The first line of defence is authentication: signed tokens (JSON Web Tokens), API keys validated at the edge, or mutual transport-layer security (mTLS) on internal-facing APIs. The second line is targeted custom rules that block any request to a versioned API path missing the expected authentication header. The third line is rate limiting, covered later.

A typical production rule on the API surface:

(starts_with(http.request.uri.path, "/api/")
 and not any(http.request.headers["x-api-key"][*] in {"<valid-key-hashes>"})
 and not cf.bot_management.verified_bot)
Action: Block

Login endpoints

Login is the highest-risk surface in any production environment. Credential-stuffing attempts, password sprays, and account-takeover campaigns all converge here. Tighten the threshold to 30 or 40, and combine bot score with leaked-credentials detection when available on your plan.

Example rule for a strict login:

(http.request.uri.path eq "/login"
 and cf.bot_management.score lt 40
 and not cf.bot_management.verified_bot)
Action: Block

For zones that authenticate through a federated identity provider, apply the same logic to the SSO callback path.

Mobile traffic

Mobile applications are where the Bot Shield case becomes obvious. Native mobile API calls do not execute JavaScript, do not render CAPTCHAs, and often hit your origin from carrier-grade NAT (network address translation) ranges that share IPs with thousands of devices. Default Bot Management will challenge legitimate users.

Two approaches that hold up in production:

1. Whitelist the official app fingerprint by JA3/JA4. Capture the fingerprint from your release build, validate it against several recent releases, and skip the bot rules for matching requests.
2. Differentiate by user agent. If you control the app, ship a custom user agent and write thresholds against it: stricter than browser, looser than anonymous.

When neither approach is enough, layer Bot Shield, which is what we did on the case described below.

Whitelisting that will not hurt later

The most common production incident on Bot Management is a verified bot list that nobody updated. A new monitoring tool is rolled out, a new partner integration goes live, a new region brings a new content-delivery network, and the rule set stops being current.

Four whitelist methods, ordered from hardest to spoof to easiest:

1. Signed agents (recently introduced by Cloudflare): cryptographically signed identity tied to a known operator.
2. JA3/JA4 fingerprint match: ties the allowance to a TLS handshake signature, harder to spoof than an IP or user agent.
3. IP range allowlist: useful for partners with static egress.
4. User-agent string match: the weakest, because user agents are trivially spoofed. Use only in combination with at least one of the above.

Document every whitelist entry, the owner, and the expected lifetime. The list is a security asset and a security liability.

How does Bot Management interact with the WAF and rate limiting?

Cloudflare evaluates rules in a fixed order: Custom Rules first, then Bot Management, then Managed Rules, then Rate Limiting. Misreading that order is the most common reason a custom rule appears not to fire.

Bot Management does not run alone. The Cloudflare security stack evaluates rules in a defined order, and a misunderstanding here is the most common source of “the rule does not fire” tickets we see at Brixio.

The simplified order on a production zone with Bot Management Enterprise:

1. WAF Custom Rules (your hand-written rules)
2. Super Bot Fight Mode (skipped if Bot Management Enterprise is on)
3. WAF Managed Rules and the OWASP Core Ruleset
4. Rate Limiting Rules
5. Cache and origin

A custom rule with the Skip action at step 1 bypasses everything that follows. That is useful for verified bots and partners. It is dangerous if applied too broadly.

The combinations we deploy most often:

• Login + Rate Limiting: bot score below 40 plus 5 requests per minute per IP plus leaked-credentials check.
• Search + Bot Score + Rate Limiting: bot score below 20 plus 60 requests per minute per session cookie on the search endpoint.
• Checkout + Strict Browser Only: bot score below 30 plus JavaScript Detections passed equals true plus rate limit per session.

For deeper guidance on the WAF and rate-limiting sides of these combinations, see the official Cloudflare WAF documentation and the Rate Limiting rules reference.

If you would rather run this bundled and managed, bot management is one pillar of our managed WAAP service, alongside WAF, API protection and DDoS mitigation.

AI bots: the 2025 layer you cannot skip

Generative-AI crawlers became a production concern in 2024 and a board-level question in 2025. Cloudflare now ships three controls that should be active on any content site or application surface where intellectual property matters.

• Block AI bots (managed setting): blocks the major AI crawlers, including Amazonbot, Applebot, Bytespider, ClaudeBot, GPTBot, Meta-ExternalAgent, PetalBot, and CCBot. Two modes: block on all pages, or block only on hostnames that serve advertising.
• AI Labyrinth: an invisible honeypot of nofollow links that traps AI crawlers ignoring robots.txt. Their fingerprints are then shared across the Cloudflare network.
• AI Crawl Control (released October 2025): granular per-crawler allow or block, with analytics and a Robots.txt tab that tracks compliance violations. This is the right place to manage AI crawler policy at scale.

A defensible baseline: enable managed robots.txt (signal layer), enable Block AI bots in the Security Settings (enforcement layer), and use AI Crawl Control to handle exceptions per crawler.

What should you monitor every week?

Bot Analytics distribution, Security Events firings, Logpush fields exported to your SIEM, and the false-positive backlog. Without weekly observation, rule sets drift.

Bot Management without monitoring drifts. Defaults age, attack patterns shift, and rule sets that fired last quarter may be silent now. The weekly review at Brixio covers four artefacts.

• Bot Analytics dashboard: distribution of scores, top verified bots, top detection IDs. Anomalies here are the leading indicator of a campaign starting.
• Security Events log: confirms that custom rules are actually matching the traffic you wrote them for. A rule that has not fired in two weeks is either misconfigured or no longer relevant.
• Logpush stream (for zones with logging enabled): export BotScore, BotScoreSrc, JA3Hash, JSDetectionPassed, and LeakedCredentialCheckResult to your security information and event management (SIEM) platform.
• False-positive backlog: a ticket queue, not a metric. If users are being challenged who should not be, the rule set is too strict and trust will erode.

The operational target we aim for on managed zones: false-positive rate below 0.1 %, definitive-automated traffic blocked above 95 %, and a documented exception list reviewed monthly.

In practice: Bot Shield on a mid-size international airline

The native mobile API of a mid-size international airline (anonymised at the client's request) had become the new battleground after the web booking funnel was hardened with WAF and Super Bot Fight Mode. The pattern in the logs was specific: bots executed partial booking flows on the iOS and Android API. They searched, temporarily held seats, and abandoned before reaching the payment step. Each temporary hold triggered the yield-management system to raise fares, inflating prices for real customers in the same fare class.

Cloudflare's web-channel defences could not see this. CAPTCHA does not run on a native mobile API.

The Brixio team deployed Bot Shield, our proprietary detection layer, alongside Bot Management. The approach:

• Four-week pilot in LOG mode, observe-only, with zero enforcement and zero traffic impact during the pilot.
• Fourteen custom detection signals tuned per API route: search, tempBooking, passenger, payment. Each route received its own scoring profile because the legitimate behaviour on each was distinct.
• JA3/JA4 fingerprint reputation as the core signal, scored against baselines of legitimate iOS and Android app traffic captured during the pilot.
• Channel-aware leniency for the airline's home-market user base, to prevent false positives on geographies that fly the most.
• Gradual enforcement rollout after stakeholder review and per-route metric sign-off.

Outcomes recorded after the rollout:

• Zero false positives during the enforcement phase.
• Infrastructure cost held on the Cloudflare free tier: Bot Shield runs on standard Workers and Bot Management fields, no Enterprise feature uplift required for this deployment.
• Bot families identified and documented per session: signals, fingerprints, ASN, country, request path, available to the revenue-protection team.
• Dashboard handed over to operations as an ongoing tool for revenue protection, under a Brixio managed-services engagement.

Where to go from here

Cloudflare Bot Management is a strong baseline. It is not a finished configuration. The difference between a deployment that lasts and a deployment that quietly leaks is the work that happens after the toggle: per-endpoint tuning, signal layering, observation, and the discipline to refresh the rule set when the attack surface moves.

Brixio operates Cloudflare zones in production across Europe, the Gulf, and APAC. As an Authorized Cloudflare Service Delivery Partner with Follow-the-Sun coverage from Luxembourg, Paris, Dubai, and Singapore, we run Bot Management as a continuous operation, not a one-off project. Tuning like this is the day-to-day work of our certified Cloudflare experts, across dozens of production zones.

If you want a read-only assessment of where your current Cloudflare configuration stands, we ship the result in five minutes.

Run a free Cloudflare audit →