Google Cloud Armor enables you to define prioritized rules with configurable match conditions and actions in a security policy. A rule takes effect, meaning that the configured action is applied, if the rule is the highest priority rule where the incoming request's attributes match those expressed in the rule's match condition.
There are two kinds of match conditions:
- A basic match condition contains lists of IP addresses or lists of IP address ranges.
- An advanced match condition contains an expression with multiple subexpressions to match on a variety of attributes of an incoming request.
The custom rules language is used to write the expressions in advanced match conditions for security policy rules. The Google Cloud Armor custom rules language is an extension of the Common Expression Language (CEL).
An expression requires two components:
- Attributes that can be inspected in rule expressions.
- Operations that can be performed on the attributes as part of an expression.
For example, the following expression uses the attributes
188.8.131.52/24 in the operation
inIpRange(). In this case, the expression
returns true if
origin.ip is within the
184.108.40.206/24 IP address range.
Attributes represent information from an incoming request, such as the origin IP address or the requested URL path.
||string||The source IP address of the request.|
||map||A string-to-string map of the HTTP request headers. If a header contains multiple values, the value in this map would be a comma-separated string of all of the values of the header. The keys in this map are all lowercase. Only the first 16 KB of each header value is available for inspection. Any header value over 16 KB is truncated per Google Cloud load balancer specifications.|
||string||The HTTP request method, such as
||string||The requested HTTP URL path.|
||string||The HTTP URL scheme such as
||string||The HTTP URL query in the format of
||string||The Unicode country code that is associated with the origin IP, such
For more information, see unicode_region_subtag in the Unicode Technical Standard.
The following reference describes the operators that you can use with attributes
k) to define rule expressions.
||Returns true if x is equal to the given constant string literal.|
||Returns true if x is equal to the given raw string literal that does not interpret escape sequences. Raw string literals are convenient for expressing strings that themselves must use escape sequence characters.|
||Returns true if x is equal to y.|
||Returns true if x is not equal to y.|
||Returns the concatenated string xy.|
||Returns true if both x and y are true.|
||Returns true if x, y, or both are true.|
||Returns true if the Boolean value x is false, or returns false if the Boolean value x is true.|
||Returns true if the string x contains the substring y.|
||Returns true if the string x begins with the substring y.|
||Returns true if the string x ends with the substring y.|
||Returns true if the string x matches the specified RE2 pattern y. The RE2 pattern is compiled by using the RE2::Latin1 option that disables Unicode features.|
||Returns true if the IP address x is contained within the IP range y. Subnet masks for IPv6 addresses cannot be larger than /64.|
||Returns the lowercase value of the string x.|
||Returns the uppercase value of the string x.|
||Returns the base64 decoded value of x; the characters
||Returns true if key k is available in the map m.|
||Returns the value at key k in the string-to-string map m if
k is available; otherwise, returns an error. Recommended approach is
to first check for availability by using
||Converts the string result of x to an
For each of these expressions, the action taken depends on whether the expression is included in a deny rule or an allow rule.
Allow or deny access based on an IP address range in IPv4 or IPv6
The following expression matches with requests from the
220.127.116.11/24IP address range:
The following expression matches with requests from the
2001:db8::/32IP address range:
Allow or deny traffic with a specific cookie
The following expression matches with requests that have a cookie containing
has(request.headers['cookie']) && request.headers['cookie'].contains('80=BLAH')
Allow or deny traffic with a non-empty
The following expression matches with requests that have a non-empty
has(request.headers['referer']) && request.headers['referer'] != ""
Deny traffic from a specific region
If your web application isn't available in the
AU region yet, all
requests from that region must be blocked.
Use the following expression, which matches with requests from the
AUregion, in a deny rule:
origin.region_code == 'AU'
The region codes are based on the
ISO 3166-1 alpha 2
codes. In some cases, a region corresponds to a country, but this is not always
the case. For example, the
US code includes all states of the United States,
one district, and six outlying areas.
To include multiple conditions in a single rule, combine multiple subexpressions.
In the following example, requests from
18.104.22.168/24(such as your alpha testers) in the
AUregion match the following expression:
origin.region_code == "AU" && inIpRange(origin.ip, '22.214.171.124/24')
The following expression matches requests from
126.96.36.199where a user agent contains the string
inIpRange(origin.ip, '188.8.131.52/32') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')
Allow or deny traffic for a request URI that matches a regular expression
The following expression matches with requests that contain the string
bad_pathin the URI:
The following expression matches with requests that have
The following expression shows case-insensitive matching for the
wordpress; it matches with
User-Agent:wordPress, and other variations of
Allow or deny traffic that contains a specific Base64 decoded value
The following expression matches with requests that have a Base64 decoded value of
has(request.headers['user-id']) && request.headers['user-id'].base64Decode().contains('myValue')
Allow or deny traffic that has zero
content-length in the HTTP body
The following expression matches requests that have a zero
content-lengthin the HTTP body:
int(request.headers["content-length"]) == 0
Preconfigured rules use preconfigured static signatures, regular expressions, or both to match on HTTP request headers and query parameters. The available preconfigured rules are based on the OWASP Modsecurity core rule set version 3.0.1. Google Cloud Armor provides two predefined expression sets:
xss-<version>: defends against cross-site scripting attacks
sqli-<version>: defends against SQL injection attacks
To list all of the available preconfigured rules, see Listing the available preconfigured rules.
For more information about preconfigured rules, see the use case Mitigate application layer attacks by using preconfigured rules.
Expression set names
Expression set names have the format
<attack category>-<version field>. The
attack category specifies the type of attacks that you want to protect against,
xss (cross-site scripting) or
sqli (SQL injection).
The supported version fields are
canary. Additions and
modifications to the rules are released in the
canary version first. When
additions and modifications are considered safe and stable, they are promoted
Expression set member IDs
An expression set contains several expressions, each with its own core rule set
(CRS) ID. For example, the expression set
xss-stable includes an expression
owasp-crs-v020901-id981136-xss, which corresponds to rule ID
version 2.9.1. You can use the CRS IDs to exclude specific expressions from
being used, which is useful if a particular expression consistently triggers a
false positive. For more information, see the false
For information about the core rule set and tuning at different sensitivity levels, see Tuning Google Cloud Armor WAF rules.
Operator for preconfigured rules
Returns true if any one of the expressions inside the specified expression set returns true.
The first argument is the name of the expression set, such as
Preconfigured rule examples
The following expression uses the
xss-stablepreconfigured rule to mitigate XSS attacks:
The following expression uses all the expressions from the
xss-stablepreconfigured rule except for member IDs
evaluatePreconfiguredExpr('xss-stable', ['owasp-crs-v020901-id981136-xss', 'owasp-crs-v020901-id981138-xss'])
The following expression uses a preconfigured rule to mitigate SQLi attacks from the
198.51.100.0/24IP address range:
inIpRange(origin.ip, '198.51.100.0/24') && evaluatePreconfiguredExpr('sqli-stable')