Match fields available for Bots rules
The Professional Mode of Bots lets you combine conditions on common match fields, such as IP, Referer, and User-Agent, to filter access requests. You can then apply a monitor, slider CAPTCHA, or block action to the requests that match the conditions. This topic uses examples to introduce the common match fields of Bots and describes how to configure the corresponding rules.
Bots Professional Mode is available only to the Enterprise plan. After a user on another plan switches to Professional Mode, the page displays guidance for upgrading to the Enterprise plan, and the user cannot configure rule matching or perform actions. To use this feature, upgrade to the Enterprise plan.
Match fields covered in this topic
The following table lists the match fields for which this topic provides a scenario-based configuration example.
| Match field | When to use it |
| User-Agent | Filter requests by the device and browser information that the User-Agent request header carries. |
| Serves static resources | Apply protection policies to requests for static files only, or to all other requests only. |
| JavaScript verified | Separate clients that can run JavaScript from clients that cannot. |
| JA3 fingerprint | Identify an SSL/TLS client by the fingerprint of its TLS handshake. |
This topic does not cover every match field. For the complete list, including fields such as IP and Referer, see Match fields. For the operators and match values that you can use in a condition, see Operators and grouping symbols and Match values.
The examples in this topic apply blocking and allowlist actions. The monitor and slider CAPTCHA actions are not demonstrated.
The examples in this topic are for reference only. Configure the corresponding Bots policies based on the actual requirements of your business.
User-Agent
User-Agent is a key field in the HTTP request header that identifies characteristics of the accessing device, such as the operating system, the type of the browser, and the version. Configure User-Agent blocklist and allowlist rules to control access sources precisely and strengthen the security protection of your business acceleration services.
Configuration example
Crawlers have recently scraped the resources of your business, which caused a sharp increase in the bandwidth costs of your domain name. Analysis shows that the User-Agent of the crawler requests contains Python-requests, and you want to block such requests. Configure the rule as follows:
In the If requests match... section, set the match field to
User-Agent, the match operator to contains, and the match value toPython-requests.
In the Then execute... section, turn on the Fake Spider Blocking switch to quickly block the matched crawlers, which impersonate search engine crawlers.
Serves static resources
A static request is a request that a client, such as a browser, sends to the server for a resource that is a static file already stored on the server, such as an audio, video, or image file. The server does not need to dynamically process or generate the resource.
The Serves Static Resources match field is a switch instead of a value. The on position (
) applies the following protection policies to static requests, and the off position (
) applies them to non-static requests.
Configuration example
An e-commerce platform finds that a large number of bots disguised as normal users request product images at a high frequency, which causes a sharp increase in ESA bandwidth costs. The platform needs a protection policy that accurately distinguishes the static resource access of legitimate users from that of malicious bots. Configure the rule as follows:
In the If requests match... section, set the match field to Serves Static Resources, the match operator to equals, and set the switch to the on position (
).
In the Then execute... section, configure protection policies such as Legitimate Bot Management, Bot Characteristic Detection, and Bot Behavior Detection. Use these policies to identify malicious bots among the matched static requests.
JavaScript verified
JavaScript detection injects a lightweight, invisible JavaScript code snippet into the accessing client in the response to an HTML page or a page view request. Requests from non-browser tools that cannot run JavaScript are blocked, whereas requests that pass JavaScript detection can continue to perform other actions.
The JavaScript Verified match field is a switch instead of a value. The on position () applies the following protection policies to the requests that have passed JavaScript detection, and the off position () applies them to the requests that have not passed JavaScript detection.
Configuration example
This example assumes that JavaScript detection is already enabled for your site to identify bots. You want to add the search engine crawlers that have passed JavaScript detection to an allowlist so that they no longer go through the protection checks of the Bot Management module. Configure the rule as follows:
In the If requests match... section, set the match field to JavaScript Verified, the match operator to equals, and set the switch to the on position (
).In the Then execute... section, click Configure to the right of Legitimate Bot Management, and then select the search engines that you want to add to the allowlist.
JA3 fingerprint
JA3 and JA4 are technical fingerprints used to identify SSL/TLS clients. JA3 analyzes the Client Hello packet in the TLS handshake and generates an MD5 hash value as a unique identifier. JA4 is an upgraded version of JA3 that supports multiple protocols and uses a readable, modular string format, which strengthens its resistance to spoofing and its extensibility. This topic covers rule configuration for JA3 fingerprints only.
Configuration example
The API of an e-commerce platform provides product price and inventory query services. Recently, a large amount of unusual traffic was found to be consuming bandwidth. Analysis showed that attackers used Python crawlers disguised as browsers to access the API, which led to data leaks and degraded business performance. To block this traffic, configure a JA3 fingerprint blocklist rule in ESA Professional Mode that matches the fingerprints of known malicious clients, such as Python-requests and Scrapy.
In the If requests match... section, set the match field to JA3 Fingerprint, the match operator to is in, and the match values to the JA3 fingerprints of the clients that you want to block. In this scenario, the clients to block are
Python-requestsandScrapy. Because a JA3 fingerprint is an MD5 hash value, enter the fingerprint of each client instead of the client name.In the Then execute... section, turn on the Fake Spider Blocking switch to quickly block the crawlers that match the conditions.
