When configuring whitelist rules, custom rules, or bot management rules, you must configure match conditions in the rules to define the request characteristics to match. This topic describes the fields and their interpretations supported by rule match conditions.
What are match conditions
Match conditions refer to the request characteristics that Web Application Firewall needs to inspect. When you configure whitelist rules, Custom rules, or Bot management, you define the Match Condition to specify the request characteristics to inspect. If a request meets the match conditions configured in a rule, the request hits the corresponding rule. WAF then applies the rule action configured in the rule to process the request accordingly, such as allowing, blocking, or verifying the request.
Match Condition consists of Match Field, Logical Operator, and Match Content. The following table shows a configuration example:
|
Match Field |
Logical Operator |
Match Content |
Description |
|
URI Path |
Contains |
|
The request matches this rule if the request path contains |
|
IP |
Belongs to |
|
The request matches this rule if the client IP is |
Supported match fields
The following table lists the fields supported by match conditions and their related rules.
-
Advanced rules definition and billing
-
Definition: A rule is an advanced rule if it meets any of the following conditions:
-
The match field is
BodyorBody Parameter. -
The logical operator is
Regular Expression MatchorRegular Expression Mismatch.
-
-
Pay-as-you-go WAF: Advanced rules and basic rules have different billing standards. For specific pricing, see Billing details.
-
Subscription WAF: Only the Enterprise edition or higher supports advanced rules. For feature differences between editions, see Editions.
-
-
Matching mechanism
-
Case sensitivity: Unless otherwise specified, the match content for all match fields is case-insensitive.
-
Encoding handling: For request content that contains common encodings such as URL encoding, HTML encoding, or Unicode encoding, the system automatically decodes the content before matching.
-
|
Match field |
Description |
Supported logical operators |
|
URI |
The Uniform Resource Identifier (URI) of a request, which indicates the path of the requested resource. Generally, URI = URI Path + Query String. The corresponding match content starts with |
|
|
IP |
The source IP address of the request, that is, the IP address of the client that initiates the request. The match content must meet the following requirements:
|
Belongs To, Does Not Belong To Note
A single protection rule supports up to 100 IP addresses or IP address ranges. For example, if a protection rule contains two match conditions with IP as the match field, the total number of IP addresses or IP address ranges in the two match conditions cannot exceed 100. Separate multiple IP addresses or IP address ranges with commas (,). |
|
Referer |
The source URL of the request, that is, the page from which the request was redirected. |
|
|
User-Agent |
The browser information of the client that initiates the request, including the browser identifier, rendering engine identifier, and version information. |
|
|
Query String |
The query string in the request, specifically the part after the question mark (?) in the URL. |
|
|
Cookie |
The cookie information in the request. |
|
|
Content-Type |
The HTTP content type specified in the request, that is, the Multipurpose Internet Mail Extensions (MIME) type information. |
|
|
Content-Length |
The number of bytes contained in the request content. Valid values: 0 to 2147483648. |
|
|
X-Forwarded-For |
The actual IP address of the client in the request. The X-Forwarded-For (XFF) header field is used to identify the original IP address of the client for requests forwarded through HTTP proxies or load balancers. This field is included only in requests forwarded by HTTP proxies or load balancers. |
|
|
Body |
The content information of the request. |
|
|
Http-Method |
The request method, including GET, POST, DELETE, PUT, OPTIONS, CONNECT, HEAD, TRACE, and PATCH. |
|
|
Header |
The header information of the request. Custom header fields are supported. |
|
|
URI Path |
The URI path of the request. |
|
|
Query String Parameter |
The parameter name of the request parameter. The request parameter refers to the part after the question mark (?) in the request URL. For example, in Note
The custom Parameter of Query String Parameter is case-sensitive. |
|
|
Server-Port |
The server port. |
|
|
File Extension |
The file extension of the requested file, for example, .png and .php. |
|
|
Filename |
The filename at the end of the request path. For example, in |
|
|
Host |
The requested domain name. |
|
|
Cookie Name |
The key name of the cookie. For example, in the cookie Note
The custom Cookie-Exact of Cookie Name is case-sensitive. |
|
|
Body Parameter |
|
|
|
Client-ID |
The client identifier (such as a browser or application), which identifies the client from which an HTTP request originates based on characteristics such as User Agent information and traffic fingerprints. Note
Supported only by the module. |
|
|
JA3 Fingerprint |
A string generated by performing MD5 hashing on key parameters during the TLS handshake, including the TLS version, cipher suite, compression algorithm, and TLS extensions. This string represents the TLS configuration of the client and is called the JA3 fingerprint. The JA3 fingerprint can be used to identify and distinguish different types of TLS clients, such as web browsers, mobile applications, and malware. Note
Supported only by the module. |
|
|
JA4 Fingerprint |
The JA4 fingerprint introduces more contextual information and algorithms, such as the browser version and operating system, to reduce the potential duplication issues caused by the JA3 fingerprint. The JA4 fingerprint can more accurately identify real users versus imposters, reducing the false positive rate. Note
Supported only by the module. |
|
|
HTTP/2 Fingerprint |
An HTTP 2.0 fingerprint generated by processing the original fingerprint of the HTTP/2 client using the MD5 algorithm. It is used to analyze and identify different clients to achieve more secure and efficient communication. Note
Supported only by the module. |
|
|
IDC |
Identifies the traffic source based on source IP attribution data. Cloud servers have lower costs and are easily exploited by malicious actors for attacks. Note
Supported only by the module. |
Equals One of Multiple Values, Does Not Equal Any Value |
|
Web SDK |
Identifies abnormal traffic based on probe information collected by Web SDK, such as the web UMID and the number of keyboard/mouse/touchscreen presses. Note
Supported only by the module. |
|
|
App SDK |
Enables fine-grained control based on probe information collected by App SDK. Note
Supported only by the module. |
|