aws waf bot control explained

AWS WAF Bot Control, Explained

AWS WAF Bot Control is a managed rule group, not a separate product with its own dashboard and SDK ecosystem the way Akamai or DataDome ship one. You add it to a Web ACL (AWS's term for a firewall policy) the same way you'd add any other managed rule group, and unlike most of the vendors in this corpus, AWS documents its rules by name, in public, with what each one inspects and what action it takes by default. That is unusually specific for this category, and this page leans on it: almost everything below is quoted or closely paraphrased from AWS's own developer guide rather than reconstructed from outside reverse engineering.

Read from AWS's own documentation on 2026-08-30.

Two protection levels, and what separates them

Bot Control ships as one managed rule group, AWSManagedRulesBotControlRuleSet, with two inspection levels a site chooses between:

Common detects "a variety of self-identifying bots, such as web scraping frameworks, search engines, and automated browsers," using "traditional bot detection techniques, such as static request data analysis." Per AWS's own framing, this level labels the traffic it recognizes and blocks the bots it cannot verify, without needing anything running client-side.

Targeted includes everything Common does and adds detection for bots that do not self-identify, meaning nothing in the request announces what it is. Targeted protections, per AWS, "mitigate bot activity using a combination of rate limiting and CAPTCHA and background browser challenges," and require a JavaScript (or mobile) SDK integration on the protected site, because the targeted rules read information the SDK collects and attaches to a token, not just the raw request.

Two sub-families of targeted rules are named directly by their prefix. Rules beginning TGT_ use "browser interrogation, fingerprinting, and behavior heuristics." Rules beginning TGT_ML_ are AWS's machine-learning layer specifically: "automated, machine-learning analysis of website traffic statistics to detect anomalous behavior indicative of distributed, coordinated bot activity," built from traffic statistics like timestamps, browser characteristics, and previous URL visited. AWS states plainly that ML is on by default for Targeted but can be turned off, in which case those rules simply do not evaluate.

The token: what ties a session's evidence together

Targeted detection runs on a token, generated by the JavaScript or mobile SDK and carried on subsequent requests, and AWS's rules read the token's state rather than re-deriving everything from scratch on every request. Two labels attached to every token matter most:

• awswaf:managed:token:id:{{identifier}}, a session identifier tied to the specific token in use, changing if the client acquires a new one.
• awswaf:managed:token:fingerprint:{{fingerprint-identifier}}, a browser fingerprint AWS computes from client signals, which "stays the same across multiple token acquisition attempts" and is explicitly "not unique to a single client," AWS's own words for a value meant to identify a device class, not a specific visitor.

A token can be accepted (present, with a valid, unexpired challenge or CAPTCHA solution, on the right domain), or rejected for one of several named reasons: rejected:not_solved, rejected:expired, rejected:domain_mismatch, or rejected:invalid. A request can also be absent a token entirely, which is its own label and, at volume, its own rule: TGT_VolumetricIpTokenAbsent specifically tracks clients sending five or more requests in five minutes without a valid token and issues a Challenge action once that threshold is crossed.

What the individual rules actually check

A sample of named rules, quoted from AWS's own rule listing, gives a concrete sense of what "browser interrogation" and "behavior heuristics" mean in practice rather than as marketing language:

Rule	What it inspects	Default action
SignalAutomatedBrowser	Indicators the client browser might be automated	Block
SignalNonBrowserUserAgent	A user-agent string that does not read as a browser at all	Block
SignalKnownBotDataCenter	Traffic originating from IP ranges typically used by bots	Block
TGT_SignalBrowserAutomationExtension	A browser extension that assists automation, e.g. Selenium IDE, present on the client even if unused	CAPTCHA
TGT_SignalBrowserInconsistency	"Inconsistent browser interrogation data" inside the token	CAPTCHA
TGT_VolumetricSession	An abnormally high request volume from one client session in a 5-minute window, versus AWS's own traffic baselines	CAPTCHA (Block at maximum confidence)
TGT_ML_CoordinatedActivityLow/Medium/High	Machine-learning-detected patterns consistent with distributed, coordinated bot activity across many IPs	Challenge / CAPTCHA / CAPTCHA
TGT_TokenReuseIpLow/Medium/High	The same token reused across more than 2, 5, or 8 distinct IPs in 5 minutes	Count / CAPTCHA / Block
TGT_TokenReuseCountryLow/Medium/High	The same token reused across more than 1, 2, or 3 countries in 5 minutes	Count / CAPTCHA / Block

The token-reuse family is worth pausing on: it does not ask whether any single request looks automated, it asks whether one browser's proof-of-legitimacy is being shared across more devices, networks or countries than a single real session plausibly touches in five minutes. That is a detection axis with no fingerprint answer at all, honest or otherwise, because the thing being scored is reuse across sessions, not any property of one session's browser.

AWS is also explicit about a category it treats differently from everything above: a maintained list of roughly 1,400 verified bots (AWS calls this "Akamai-style" verification the same idea by a different name; search engine crawlers, monitoring services, SEO tools) that Bot Control identifies and does not block, adding a bot:verified label plus category and organization labels instead. A newer addition, Web Bot Authentication, lets a bot cryptographically sign its requests against a public key directory; a verified signature (web_bot_auth:verified) causes the category-block and TGT_TokenAbsent rules to skip that request entirely, a mechanism for bots that want to identify themselves honestly and be let through rather than evade detection.

What an engine answers honestly, and what a browser cannot touch

SignalAutomatedBrowser, TGT_SignalBrowserAutomationExtension, and TGT_SignalBrowserInconsistency are the rules a real, engine-level browser answers by construction: a genuinely real Firefox, patched below the JavaScript layer rather than scripted from a content script, does not carry automation-framework tells, does not have a Selenium-style extension installed, and does not produce internally inconsistent browser-interrogation data, because nothing is faking any of those signals from the inside. That is the same argument this corpus makes for BotD and CreepJS, applied to a managed rule group instead of an open-source script.

Several rule families sit entirely outside what any browser engine can affect. SignalKnownBotDataCenter and the cloud-service-provider signal read the network origin, not the browser. The TGT_VolumetricSession and TGT_TokenReuseIp/Country/Asn families score session and token behavior across time and across requests, a property of how the automation is orchestrated (how many machines, how many networks, how fast) rather than of the browser rendering any one page. And TGT_ML_CoordinatedActivity, by AWS's own description, runs on aggregate traffic statistics across a site's whole visitor population, comparing against a baseline no single session's engine fidelity can influence.

invisible_playwright does not claim to defeat AWS WAF Bot Control's targeted protections as a system. It answers the automation-signature and browser-consistency rules honestly, because there is no override for them to catch, and it has nothing to say about IP reputation, token-reuse patterns across a fleet of sessions, or AWS's own traffic-baseline machine learning, all of which are orchestration-level properties, not engine-level ones.

Short answers to the questions that lead here

What is the difference between Common and Targeted protection? Common uses static, self-identifying signals (user-agent strings, known scraping-framework patterns) and needs no client-side code. Targeted adds fingerprinting and behavior heuristics via a JavaScript/mobile SDK, plus a token that carries proof of a passed challenge or CAPTCHA across requests.

What is the AWS WAF token, exactly? A piece of state the SDK generates and attaches to requests, carrying a session identifier, a browser-fingerprint identifier, and the status of any challenge or CAPTCHA solve. Rules check the token's status (accepted, rejected:*, absent) rather than re-scoring every request from nothing.

Does AWS WAF Bot Control use machine learning? Yes, in the TGT_ML_ rule family specifically, trained on traffic statistics like timestamps, browser characteristics and prior URLs visited, aimed at distributed coordinated activity rather than any single request. It is on by default for Targeted protection and can be disabled.

What is token reuse, and why does it matter? The same proof-of-legitimacy token appearing across multiple IPs, countries, or ASNs within a five-minute window. It is a detection axis with no browser-level answer, because it scores how a token is being shared, not what any individual session's browser does.

Does Bot Control block search engines and other known-good bots? No. AWS maintains a verified-bot list (~1,400 entries) that gets labeled and passed rather than blocked, and a newer cryptographic mechanism, Web Bot Authentication, lets a bot sign requests to prove its identity instead of being challenged.

Does a real browser engine defeat AWS WAF Bot Control? It answers the automation-signature and browser-consistency rules honestly, which removes that whole failure class. It has no bearing on IP/data-center signals, token-reuse-across-sessions rules, or the ML-based coordinated-activity detection, all of which operate above the level of any single browser.

Does invisible_playwright bypass AWS WAF Bot Control? No. This project does not sell or claim a bypass service for AWS WAF or any comparable vendor.

See also: How do websites detect bots? for where a managed-rule-group check like this sits among the other layers; ASN and IP reputation in bot detection for the network-origin signals Bot Control's data-center rule leans on; and How Cloudflare Turnstile actually works for a comparably-documented token-and-challenge model from a different vendor.

Sources

• AWS, AWS WAF Bot Control components, retrieved 2026-08-30, for the Common/Targeted protection-level distinction, the TGT_/TGT_ML_ rule-name conventions, and the SDK/token integration requirement.
• AWS, AWS WAF Bot Control rule group, retrieved 2026-08-30, for the full rule listing quoted in the table above, the token status labels (accepted/rejected:*/absent), the verified-bot list and Web Bot Authentication mechanism, and the token-reuse rule thresholds.
• AWS, Using managed rule groups in AWS WAF, retrieved 2026-08-30, for how a managed rule group is added to a Web ACL.

---

From the notes of invisible_playwright, a Firefox patched at the C++ level. AWS documents its Bot Control rules more specifically, by name and by default action, than almost any other vendor in this corpus, which is why this page quotes rule names directly rather than reconstructing them from outside reverse engineering.