When an HTTP request reaches Cloudflare’s edge, Cloudflare creates a table of field–value pairs against which to match expressions. This table exists for as long as the current request is being processed.
The values that populate Firewall Rules lookup tables are drawn from a variety of sources:
- Primitive properties are obtained directly from the request (
http.request.uri.path, for example).
- Derived values are the product of a transformation, composition, or basic operation. For example, the transformation
lower(http.request.uri.patch)converts the value of
- Computed values are the product of a lookup, computation, or other intelligence. For example, Cloudflare uses a machine learning process to dynamically calculate threat scores, represented by the
When working with values in Firewall Rules expressions, keep in mind the notes outlined below for escape characters, case sensitivity, and boolean values.
Escape characters in values
You must manually escape the backslash (
\) and double quote (
") characters with a backslash when using them as part of a literal value in an expression.
Note in this example that the first and last
" characters in
"token-type=\"JWT\"" are not part of the literal value, so they do not need escaping:
(http.request.uri.query contains "token-type=\"JWT\"")
Case sensitivity and regular expressions in values
Since the evaluation of expressions using string values is case-sensitive, consider writing more than one simple expression to capture variants.
Simple expressions using boolean fields do not require operator notations or values. You only need to insert the field on its own, as shown in the
ssl example below.
This simple expression matches requests where the value of the
ssl field is
To match requests where
false, use the boolean
not operator :
To refer to a Rules List in a firewall rules expression, use $<list_name> and specify the
in . This example expression filters requests from IP addresses that are in a Rules List named office_network:
(ip.src in $office_network)