Bot Management — Full Curriculum

Personal study reference, not customer-facing. Built to answer anything that could come up on a real call — fundamentals, all four plan tiers, detection internals, configuration, AI crawlers, and troubleshooting. Every fact below is sourced from live Cloudflare docs (full list at the bottom); nothing here is from memory alone.

Module 1Fundamentals — what Bot Management actually is

Bot Management doesn't block anything by itself. It quietly scores every request, then you (or a simpler built-in toggle) decide what to do with that score. Think of it as a guard taking notes, not a guard at the door.

The Bot Score

Every request gets an integer from 1 to 99. Lower = more likely automated. Higher = more likely human. This direction trips people up constantly — it's backwards from what feels intuitive ("high score = high bot confidence"), so drill it: low score, bot. high score, human.

"Bot groupings" (this categorized view) is visible to Pro plan and higher under Security > Bots — not Enterprise-only.

What do you actually DO with a score? Block vs. Challenge vs. Allow vs. Skip

This is the question everything above is building toward, and it's worth being explicit: these are four different things, not four points on one scale. Allow/Block/Challenge are the three verdicts for how matched traffic gets treated. Skip is not a fourth verdict — it's a completely different mechanism that exempts traffic from an entire feature before that feature ever renders a verdict at all.

Score ranges above are field guidance from a real Cloudflare Bot Management SE on an actual customer call (see Module 7), not an official documented standard — validate in Log mode against your own traffic before committing to a cutoff.

Putting the score ranges and field guidance from elsewhere in this doc into one practical sequence:

1. Is this a Verified Bot you actually want? → Allow it, done.
2. Is this your own known-good automated traffic that risks getting caught by a rule meant for bad bots? → Skip the specific feature (SBFM, Managed Rules, etc.) for it, set up first.
3. Everything else gets judged by score: 1 and the 2–10 range → generally safe to Block (very low false-positive risk). 11–29 → fuzzier, default to Challenge — this is exactly the range where real users on compromised residential-proxy devices tend to land (see Module 7). 30–99 → leave it alone entirely.
4. No descriptive tag on the detection, even at a low score? Lean toward Challenge over Block — per field notes, an untagged detection runs roughly 80–95% confidence vs. ~99.99% for something Cloudflare is confident enough to actually name.
5. Adjust everything above by business model: ad-revenue/consumer sites skew toward Challenge (a wrongly-blocked real user costs money and generates support tickets); paywalled or banking sites can reasonably skew more aggressive toward Block.

And always: new rule goes into Log mode first, for days not hours, before it ever actually blocks or challenges anything live.

The __cf_bm cookie

Cloudflare sets this cookie to smooth a single user's score across their session, reducing false positives caused by one weird request in an otherwise-normal session. It measures a user's request pattern and feeds that into the ML scoring for the rest of their requests. Enterprise customers can disable it via the API (bm_cookie_enabled) — normally there's no reason to.

Module 2How detection actually works

Cloudflare runs several detection engines in parallel, because different bot types need different strategies. Which engines apply to you depends on your plan — see Module 3.

Heuristics

Runs on every request, every plan. Pattern-matches against a continuously growing database of known malicious fingerprints. Deterministic, not probabilistic — when Heuristics fires, it's usually a score of 1 (high-confidence, no ambiguity). Occasionally sets a score of 29 when it's identified automation but is still assessing overlap with legitimate traffic.

Adaptive Intelligence (the ML engine) — Business & Enterprise

This is the renamed, upgraded version of what used to just be called "the ML engine" — accounts for the majority of all bot detections. It's a supervised model: input is request features (headers, session characteristics, browser signals) collected across Cloudflare's entire network (billions of requests/day); output is the predicted probability a client is human, mapped to the 1–99 score.

The important recent change: Adaptive Intelligence retrains continuously instead of shipping as a fixed, numbered version months or years apart. New bypass tools and bot frameworks get folded in without waiting for a scheduled release. Every update runs in shadow mode first (scored but not acted on) and is validated against the current model before rolling out gradually — so a bad update can't silently break your rules overnight. Enterprise customers need "Auto-update machine learning" turned on (Security Settings → Bot traffic → Bot Management → Configurations) to actually get Adaptive Intelligence; otherwise you stay on a fixed model version. Model updates never change your WAF rules or challenge flows directly, but scores can shift as the model learns — periodically sanity-check rules that key off a specific score threshold.

Anomaly Detection — being deprecated

Unsupervised learning, baselines your domain's own traffic and flags outliers. Cloudflare is deprecating this engine and not onboarding new customers — future behavioral detections will cover the same ground differently. Don't position this as a current recommendation. Not recommended historically for Cloudflare for SaaS zones or high-API-traffic domains (it immediately scores automated-looking requests a 1, which is too aggressive for those patterns).

JavaScript Detections (JSD)

Orthogonal to score — checks something the network-level engines can't: can this client actually execute JavaScript like a real browser? A script can fake headers and look clean on the network side but can't run JS. JSD performs a lightweight, invisible, privacy-safe injection and either blocks, challenges, or passes the request to other engines. It does not feed into or change the bot score — js_detection.passed = true and score = 1 can both be true on the same request if another heuristic independently flagged it. Best applied narrowly: login, checkout, account pages — not site-wide, since legitimate users with JS disabled, ad blockers interfering, or network issues can cause real false failures. Use Managed Challenge as the action, never a hard Block. On Free-plan Bot Fight Mode, JSD is automatically on and can't be disabled.

Precursor — supersedes JavaScript Detections

Client-side JavaScript enabling continuous, session-based behavioral detection, rolled out to all customers starting July 2026. Where JSD was a one-time check, Precursor evaluates behavioral signals throughout a session, can re-validate challenge clearance as behavior changes mid-session, and can update bot scores with that session context. It officially supersedes JSD — both collect client-side signals, but Precursor does it continuously instead of once.

Configured via two modes, settable per-path with Precursor Rules: Minimize Friction (lighter touch, good for a homepage or public API) and Maximize Security (requires a valid cf_clearance cookie — good for checkout/login, but will break non-browser clients like curl, server-to-server jobs, or fetch/XHR calls that don't send cookies unless you explicitly set credentials: "include"). A common pattern on mixed HTML+API zones: Minimize Friction globally, Maximize Security only on sensitive paths — or the reverse, with Minimize Friction carved out for API hostnames.

JA3 / JA4 fingerprinting — Enterprise Bot Management only

A TLS/SSL client fingerprint — profiles a specific client across different destination IPs, ports, and certificates, independent of anything in the HTTP headers (which a bot can freely fake). JA4 is the newer, more detailed version of JA3. Available as cf.bot_management.ja3_hash and cf.bot_management.ja4 in custom rules, and as a rate-limiting counting characteristic when an app has no session cookie to key off of.

There's also JA4 Signals Intelligence — per-fingerprint stats computed hourly across the whole Cloudflare network: ratio of browser vs non-browser user agents, HTTP/2+3 ratio, request-path diversity rank, cacheable-response ratio, and more. This lets you distinguish "this fingerprint looks like a normal browser population" from "this fingerprint is unusually concentrated and robotic" even before you've seen much of your own traffic from it.

Verified Bots

A completely separate axis from the score — identity confirmed independently, not a probability guess. To be Verified, a bot must clear two bars: (1) honest self-identification — via a cryptographic Web Bot Auth signature, a published stable IP list, or reverse DNS — and (2) non-abusive behavior — obeys robots.txt, reasonable request rates, no history of evading site-owner preferences.

Verified bots are classified as Direct (single operator, own infrastructure — e.g. Googlebot) or Intermediary (an agentic service many different end users can drive — the operator runs the software, but each action is initiated by someone else). This matters because with an intermediary, trusting the operator doesn't mean trusting every end user behind it — Cloudflare is experimenting with forwarding end-user info via the Forwarded header (RFC 7239) so site owners can apply policy to whoever's actually responsible for a given request.

BotBase (Enterprise Bot Management only) is the searchable directory of every known bot — shows how Cloudflare classifies each one, lets you filter your own traffic to a specific bot, copy its detection ID straight into a security rule, and lets anyone operating a bot submit it for verification with status tracking (Waiting for Review / Accepted / Rejected / Cancelled).

Module 3The four plan tiers, in full

This is the part worth memorizing cold — plan confusion is probably the single most common type of question on a real call.

Settings vs. custom rules — where the real gap is

This table is the thing to internalize: it's not just "higher plan = more power," it's specifically about whether you need to write a rule or whether Cloudflare just handles it for you in Security Settings.

Notice the Enterprise+BM column is mostly "custom rules only" — that's the trade: you give up the simple toggle in exchange for continuous-score precision (block score 1–7, challenge 8–29, different thresholds on your login page vs. your public blog, etc.). Bot Management customers typically start with the baseline bot settings for general protection, then layer custom rules only where they need finer control — not replace settings entirely on day one.

Module 4Rules & configuration

Before touching any setting — review traffic first

1. Go to the Analytics page.
2. Select the Bot analysis tab (Business plan and above for full score-distribution data; Free/Pro see basic metrics via Security Events instead).
3. Review the bot score distribution chart, top requested paths getting bot traffic, and any traffic pattern spikes before changing a single setting.

This is Cloudflare's own stated order of operations — understand what's actually happening on the domain before flipping anything on. Skipping this step is how someone turns on an aggressive rule and immediately blocks a legitimate integration they didn't know existed.

How to actually turn this on, by plan

Bot Fight Mode (Free):

1. Go to the Security → Settings page.
2. Filter by Bot traffic.
3. Turn Bot fight mode on.

Remember from Module 3: this is all-or-nothing, domain-wide, can't be scoped or Skipped — there is no dashboard nuance to walk through beyond the single toggle.

Super Bot Fight Mode (Pro/Business):

1. Go to the Security → Settings page.
2. Filter by Bot traffic.
3. If upgrading from Bot Fight Mode, turn Bot fight mode off first — they don't coexist.
4. Go to Super Bot fight mode, turn it on.
5. Use the edit icon next to each traffic category (Definitely Automated, Likely Automated if on Business, Verified Bots, static resources, JS detections) to set its response.

Bot Management (Enterprise): no self-serve toggle — it's a paid add-on, contact your account team to add the subscription. Once active, go to Security Settings → Bot traffic → Bot Management → Configurations and turn on Auto-update machine learning to actually get the continuously-retrained Adaptive Intelligence model (Module 2) instead of staying on a fixed version.

Evaluation order

The full, precise order across both account and zone level (confirmed from the Ruleset Engine phase reference) — this is the thing to have memorized when someone asks "which rule actually fired":

Then Super Bot Fight Mode runs after all of that, in its own phase (http_request_sbfm) — fixed, not configurable. Bot Fight Mode (Free) doesn't run on the Ruleset Engine at all — it's a separate pipeline where Skip/Bypass/Allow have zero effect, which is exactly why it can't be excepted the way SBFM can.

The Skip action — your main tool for exceptions

(See Module 1's "What do you actually DO with a score" for how Skip fits alongside Allow/Block/Challenge — this section is the mechanics.)

Non-terminating — lets a matching request bypass a specific security feature instead of being blocked outright. Works for Super Bot Fight Mode, Managed Rules, Rate Limiting, remaining custom rules. Does not work on Bot Fight Mode — SBFM or higher only. Typical use: exempt a payment processor's IP, a monitoring tool, or Cloudflare Tunnel/WARP traffic (which can break under SBFM with a websocket: bad handshake error if "Definitely Automated" isn't set to Allow).

// Skip rule example (Security rules → Custom rules)
// Match: ip.src eq 192.0.2.1
// Action: Skip → All Super Bot Fight Mode rules

Example custom rules using the score (Enterprise + Bot Management)

// Block confidently, exempt verified bots/static assets/corporate proxies
not cf.bot_management.verified_bot
and not cf.bot_management.static_resource
and not cf.bot_management.corporate_proxy
and cf.bot_management.score lt 30

// Rate-limit by JA3 fingerprint instead of a session cookie
// Matching: Bot Score < 10 AND URI Query contains "action=delete"
cf.bot_management.score lt 10 and http.request.uri.query contains "action=delete"
// Counting characteristic: JA3 fingerprint (when no session cookie exists)

// Challenge non-bot POSTs to /login, see results, then tighten to Block
(http.request.uri.path eq "/login" and http.request.method eq "POST" and not cf.client.bot)
// Action: Managed Challenge -> review Security Events -> switch to Block if clean

Why Skip instead of just loosening the block rule?

Loosening a block's own criteria weakens it for everyone — attackers can often spoof the exact signal you relaxed. A narrow Skip scoped to something harder to fake (a known IP, a verified-bot flag, an auth token) protects the one legitimate case without opening the door wider for anyone else.

How to actually create one of these rules

1. Go to the Security rules page.
2. Select Create rule → Custom rules.
3. Enter a descriptive Rule name.
4. Under When incoming requests match, build or paste the expression (e.g. cf.bot_management.score lt 10 plus whatever else scopes it).
5. Under Then take action, choose Skip if exempting traffic, or Log / Managed Challenge / Block if enforcing.
6. If using Skip, choose exactly which feature(s) to skip — All Super Bot Fight Mode rules, Managed Rules, Rate Limiting, or remaining Custom Rules — don't default to skipping everything when you only need to exempt one feature.
7. Select Deploy.

Module 5AI crawlers, AI Labyrinth & Pay Per Crawl

This is the newest and fastest-moving part of the product — expect questions here to keep changing.

Block AI Bots

Available on every plan, including Free. A single toggle (Security Settings → Bot traffic) that blocks known AI crawlers outright. You can also configure the block response: 403 Forbidden or 402 Payment Required, with a custom message (e.g. licensing contact info).

Turn it on: Security → Settings → filter Bot traffic → toggle on. Configure the block response (paid plans): go to AI Crawl Control → Settings tab → Block response → Edit → choose 403 or 402, write the response body, Save. Note: you must already be blocking at least one AI crawler before this response-editing option becomes available.

AI Labyrinth

A honeypot, not a mitigation. Injects invisible links with Nofollow tags into your pages — real users and compliant crawlers never see them (no SEO impact), but a non-compliant AI crawler that ignores your crawl rules falls into a maze of never-ending links, wasting its own resources. Cloudflare records details from crawlers caught this way and shares that signal across all customers who choose to block AI bots. Logged in Security Analytics under the AI Labyrinth service: Served (honeypot link injected) vs. Crawls (a bot actually followed one in). A high Crawls-to-Served ratio means non-compliant crawlers are actively active against you. Turning it off stops new links from being injected, but previously-generated links stay valid for a limited time — don't mistake lingering activity for the toggle not having worked.

Turn it on: Security → Settings → filter Bot traffic → go to AI Labyrinth → toggle on. That's the entire setup — no further configuration exists for this feature.

Pay Per Crawl (closed beta)

Lets a site owner charge AI crawlers per successful content access instead of just blocking them — Cloudflare acts as Merchant of Record and provides the payment infrastructure (managed via Stripe). Minimum price: $0.001 per crawl; dynamic pricing by content is available. Per crawler, you choose one of three actions: Allow (free access), Charge, or Block. A crawler either presents payment intent via request headers for a successful 200, or gets an HTTP 402 Payment Required with pricing info.

Watch the SEO tradeoff: setting a Search Engine Crawler (anything tagged as such in AI Crawl Control) to Block or Charge can hurt indexing — the dashboard explicitly warns about this. Blocking a company's own AI crawler can also mean that company's AI product stops citing or answering about the site at all — the AI-era equivalent of losing SEO visibility (sometimes called AEO, answer-engine optimization). With thousands of individual detection IDs for different crawlers, use category-based rules plus a specific allowlist exception for any one AI company the customer still wants visible.

Module 6Troubleshooting & false positives

Standard workflow

1. Go to Security > Analytics > Events, find the blocked/challenged request.
2. Check the Service field — it names exactly which product took the action (SBFM, Managed Rules, a specific custom rule, etc.), telling you where to go fix it.
3. Look for the classic false-positive signatures: known monitoring/payment-processor IPs in blocked events, legitimate browser user-agents getting challenged, high challenge volumes from countries where you actually have real users.
4. For Managed Challenge rules specifically, check the Challenge Solve Rate (CSR) — a low CSR usually means the rule is correctly filtering bots, not hurting real users.

Resolving false positives, by product

Bot Fight Mode and SBFM are aggressive by design — some false positives in the first few days after turning either on is expected, not a sign something's broken.

The feedback loop — improving accuracy over time

Enterprise Bot Management customers can report both false positives and false negatives directly from Security Analytics → Bot analysis → "Report incorrect data." This feedback trains future model versions — don't quote specific internal model version numbers to a customer as official terminology, it isn't public. After submitting a false negative, you can explicitly block/rate-limit the missed traffic using IP, JA3 fingerprint, ASN, or user-agent — but check Bot Analytics first to confirm that JA3 fingerprint isn't shared with legitimate traffic before blocking on it alone.

Module 7Field notes — real deep-dive with a Bot Management SE

Pulled from an actual customer call where a Cloudflare Bot Management SE walked through real traffic analytics in detail. This is practitioner color, not restated documentation — flagged clearly anywhere it's a professional judgment call rather than a documented fact.

Residential proxies — the real #1 detection target

Per a real Cloudflare SE's description of actual customer traffic: residential proxy ASNs were the single largest detection category by volume — described as "the new VPN evil." Attackers who used to bounce through VPNs to evade geo-blocking (e.g. Russia/China traffic) now bounce through residential proxy services (Bright Data and similar) instead, because it's effectively free, distributed, and much harder to block by IP range. The dark side: many of these "residential" IPs are real home devices compromised without the owner's knowledge — the SE's example was literally a grandparent's device, unknowingly part of a proxy network while they do completely normal browsing (shopping, email) from the same IP. This is the direct argument for Challenge over Block on fuzzy-range traffic for any consumer-facing business: an outright block can catch real customers on compromised home devices, generate real support complaints, and in some business models (anything ad-revenue-funded, where every pageview is worth something) directly costs money. A bank or paywalled service can reasonably be far more aggressive than a tabloid news site living on ad impressions — there's no universal right answer, it's a real business-model tradeoff every time.

ASN / BGP peering anomalies

A real-world detection wrinkle worth knowing: ASN peering relationships can produce traffic that looks anomalous purely from how the internet is routed, not from anything the requester did. Example given: a Russian carrier peering through a Florida-based ASN that accepts traffic/payment from essentially anyone — the result is Russian-origin IPs appearing to come from a US carrier, which can trip an ASN-based anomaly flag even though it's just an artifact of carrier-level peering economics, not necessarily malicious intent on its own.

"Shadow crawling" and deliberately-imprecise detections

Cloudflare intentionally keeps some detections less than fully transparent for certain known entities (the example given was AI companies like Perplexity) specifically so they can't reverse-engineer exactly which signals (malformed headers, specific TLS/JA3 fingerprint quirks, etc.) are being used to identify them — publishing the exact detection logic would let them trivially evade it. This is also why a meaningful share of detections intentionally carry no descriptive tag: a tag only gets attached once Cloudflare is confident enough in a specific identity to publish it. A concrete example of the kind of signal that does get used: a client claiming to be HTTP/1.1 but sending it in the wrong case (lowercase instead of the spec's uppercase) — a small, easy-to-miss tell that a script is manually constructing requests rather than using a real HTTP client.

Rough confidence levels described: Verified Bots (reverse DNS + ASN/BGP-confirmed identity, not a signature guess) are effectively 99.99%+ accurate. A named-but-unverified detection (has a descriptor but isn't Verified) runs roughly 80–95% confidence depending on the specific signature. No descriptor at all means Cloudflare is confident something is automated, but not confident enough in the specific identity to label it — treat these more cautiously before blocking outright, since this bucket is where real users on compromised/obscured devices are likeliest to land.

Practitioner score-threshold guidance (field judgment, not an official number)

Official docs correctly say "no universal cutoff, test in Log mode first" — true, and still the right process. For a concrete starting point a real SE actually gave on a real call: scores 2–10 were described as safe to block with few expected false positives; 11–29 as meaningfully fuzzier, generally safer to Challenge than Block, with the exact cutover point depending entirely on the business's tolerance for false positives; 29 and below as a generally-safe Challenge threshold. Treat these as a reasonable starting hypothesis to validate in Log mode against your own traffic — not a documented Cloudflare standard.

DDoS visibility — a real limitation, confirmed by both docs and a live SE

Layer 3/4 DDoS mitigation will never show up in WAF/Security Events logs — it's handled entirely separately, automatically, on every plan, with a deliberately conservative posture (described as targeting obvious network-level amplification/UDP-style attacks) specifically because you can't tune it yourself. Layer 7 protections, by contrast, are fully tunable. If a customer asks "would a DDoS attack show up in our WAF logs," the honest answer is no — different system, not a visibility gap in your configuration.

"How do you tell a VPN apart from a data center bot?" — a question that keeps coming up with no single clean answer

There is no dedicated "is this a VPN" field — don't invent one if asked. What actually happens is a combination of signals already covered elsewhere in this doc: ASN classification (IP Intelligence tracks "infrastructure type of the ASN" — data-center IP ranges are well-catalogued and feed into the score), the Corporate Proxy field (Enterprise-only, flags known corporate VPN/secure-web-gateway services specifically), and the general heuristics/ML score. A traditional commercial VPN's exit nodes typically sit on recognizable hosting/datacenter ASNs, which is exactly why VPN-style evasion is declining — see the residential proxy note above. The honest, complete answer to this question is the residential proxy point: attackers increasingly skip datacenter/VPN ASNs entirely and route through compromised home devices specifically because datacenter ASN traffic is easier to flag.

Framing that lands well in a business conversation

Two pieces of positioning color, not technical fact: automated traffic now outweighs human traffic on the internet overall — a real stat worth having ready when a prospect assumes bots are a minor edge case. And on cost-justifying the add-on: frame Bot Management against the avoided cost — engineering hours spent manually mitigating a scraping incident after the fact versus a rule that was already in place, not just a flat license-fee comparison. Useful specifically when a customer is trying to build an internal TCO case to their own finance team.

Module 8Live demo & test commands

Five real requests, five distinct signals — pulled from the companion Bot_Management_Demo_CheatSheet.html, which has the full live-call narrative. This is the reference version: each test cross-linked to the module that explains the mechanism behind it. Core idea running through all five: same URL, same 200 response, same body — but five visibly different rows in Security Analytics. Detection is the valuable half; once you can see the difference, acting on it is a one-rule change in the WAF.

Tests 1-2 — the human/bot baseline (Module 1: the score)

// TEST 1 — Real browser baseline. Open in Chrome:
https://nginx.tarheel.us/?demo=t1
// Expect: bot score in the human range, JA4 identifies Chrome, UA matches JA4

// TEST 2 — Honest curl (no deception)
curl -sI "https://nginx.tarheel.us/?demo=t2" | grep -E "HTTP|cf-ray"
// Expect: bot score in the bot range, JA4 identifies curl, UA says curl — everything consistent

Tests 3-5 — where JA3/JA4 fingerprinting (Module 2) actually earns its keep

// TEST 3 — Lying curl: User-Agent claims Chrome, TLS handshake says curl
curl -sI -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" \
  "https://nginx.tarheel.us/?demo=t3" | grep -E "HTTP|cf-ray"

This is the payoff row: same JA4 as Test 2 (same actual client), but the UA now claims Chrome. Those two facts can't both be true for a real browser — a genuine Chrome client produces a Chrome JA4. The deception is visible as two columns in Analytics disagreeing with each other, not a guess.

// TEST 4 — Fake Googlebot
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://nginx.tarheel.us/?demo=t4" | grep -E "HTTP|cf-ray"
// Expect: verified_bot = false — Cloudflare checked the real Google IP ranges and this isn't one

// TEST 5 — Empty User-Agent
curl -sI -A "" "https://nginx.tarheel.us/?demo=t5" | grep -E "HTTP|cf-ray"
// Expect: blank UA column, a visually distinct row shape

Run all four curl tests at once and collect Ray IDs

run_test() {
  LABEL="$1"; UA="$2"; TAG="$3"
  RAY=$(curl -sI -A "$UA" "https://nginx.tarheel.us/?demo=$TAG" | grep -i '^cf-ray:' | awk '{print $2}' | tr -d '\r')
  printf "%-20s  cf-ray=%s\n" "$LABEL" "$RAY"
}
run_test "Honest curl"        "curl/8.7.1" t2
run_test "Lying curl (Chrome)" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" t3
run_test "Fake Googlebot"     "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" t4
run_test "Empty UA"           "" t5

Acting on it — three real WAF rules (Module 4: rules & configuration)

// The rule 90% of customers should lead with — acts on the aggregate score,
// not any single fingerprint
(cf.bot_management.score lt 20)   ->   Managed Challenge

// The precision rule — catch the liar from Test 3. Note what it actually
// keys on: not "block this JA4," but "block this JA4 WHEN it's also lying
// about being a browser." A real curl client hitting an API is untouched.
(cf.bot_management.ja4 eq "<JA4 copied from the Test 3 row>"
   and http.user_agent contains "Chrome")   ->   Block

// The emergency rule — a fire extinguisher, not a smoke detector. Only for
// an active attack where many IPs share one non-browser JA4. Remove it once
// the attack subsides; that fingerprint could belong to a real client later.
(cf.bot_management.ja4 eq "<attacker JA4>")   ->   Block   [temporary]

Why show the JA4 at all, if blanket-blocking it is a bad idea?

• Explainability — when a request scores a 1, the JA4 is the evidence: "claimed to be Chrome on Windows, fingerprint is actually a Python runtime." Turns the ML score into something an engineer can audit.
• Signals Intelligence (Module 2) — Cloudflare tracks every JA4 network-wide; a JA4 with a browser_ratio near zero is a safe signal to build targeting logic around.
• Compound rules — the precision rule above only works because JA4 exists as an ingredient to combine with other signals, not as a standalone switch.

Module 9Rapid-fire Q&A

Self-testQuiz

Click a question to reveal the answer. No peeking before you commit to one.