**Introducing a new console experience for AWS WAF** You can now use the updated experience to access AWS WAF functionality anywhere in the console. For more details, see [Working with the console](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html). # Using match rule statements in AWS WAF This section explains what a match statement is and how it works. Match statements compare the web request or its origin against criteria that you provide. For many statements of this type, AWS WAF compares a specific component of the request for matching content. Match statements are nestable. You can nest any of these statements inside logical rule statements and you can use them in scope-down statements. For information about logical rule statements, see [Using logical rule statements in AWS WAF](waf-rule-statements-logical.md). For information about scope-down statements, see [Using scope-down statements in AWS WAF](waf-rule-scope-down-statements.md). This table describes the regular match statements that you can add to a rule and provides some guidelines for calculating protection pack (web ACL) capacity units (WCU) usage for each. For information about WCUs, see [Web ACL capacity units (WCUs) in AWS WAF](aws-waf-capacity-units.md). | Match Statement | Description | WCUs | | --- | --- | --- | | [Geographic match](waf-rule-statement-type-geo-match.md) | Inspects the request's country of origin and applies labels for the country and region of origin. | 1 | | [ASN match](waf-rule-statement-type-asn-match.md) | Inspects the request against an ASN associated with IP addresses and address ranges. | 1 | | [IP set match](waf-rule-statement-type-ipset-match.md) | Inspects the request against a set of IP addresses and address ranges. | 1 for most cases. If you configure the statement to use a header with forwarded IP addresses and specify a position in the header of Any, then increase the WCUs by 4. | | [Label match rule statement](waf-rule-statement-type-label-match.md) | Inspects the request for labels that have been added by other rules in the same protection pack (web ACL). | 1 | | [Regex match rule statement](waf-rule-statement-type-regex-match.md) | Compares a regex pattern against a specified request component. | 3, as a base cost. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. | | [Regex pattern set](waf-rule-statement-type-regex-pattern-set-match.md) | Compares regex patterns against a specified request component. | 25 per pattern set, as a base cost. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. | | [Size constraint](waf-rule-statement-type-size-constraint-match.md) | Checks size constraints against a specified request component. | 1, as a base cost. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. | | [SQLi attack](waf-rule-statement-type-sqli-match.md) | Inspects for malicious SQL code in a specified request component. | 20, as a base cost. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. | | [String match](waf-rule-statement-type-string-match.md) | Compares a string to a specified request component. | The base cost depends on the type of string match and is between 1 and 10. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. | | [XSS scripting attack](waf-rule-statement-type-xss-match.md) | Inspects for cross-site scripting attacks in a specified request component. | 40, as a base cost. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. | # Geographic match rule statement This section explains what a geographic match statement is and how it works. Use geographic or geo match statements to manage web requests based on country and region of origin. A geo match statement add labels to web requests that indicate the country of origin and the region of origin. It adds these labels regardless of whether the statement criteria is a match for the request. A geo match statement also performs matching against the request's country of origin. ## How to use the geo match statement You can use the geo match statement for country or region matching, as follows: + **Country** — You can use a geo match rule by itself to manage requests based solely on their country of origin. The rule statement matches against country codes. You can also follow a geo match rule with a label match rule that matches on the country of origin label. **Note** To filter traffic from Hong Kong, use the ISO 3166-1 alpha-2 country code `HK` in your geo match statement. + **Region** — Use a geo match rule followed by a label match rule to manage requests based on their region of origin. You can't use a geo match rule alone to match against region codes. For information about using label match rules, see [Label match rule statement](waf-rule-statement-type-label-match.md) and [Web request labeling in AWS WAF](waf-labels.md). ## How the geo match statement works With the geo match statement, AWS WAF manages each web request as follows: 1. **Determines the request's country and region codes** — AWS WAF determines the country and region of a request based on its IP address. By default, AWS WAF uses the IP address of the web request's origin. You can instruct AWS WAF to use an IP address from an alternate request header, like `X-Forwarded-For`, by enabling forwarded IP configuration in the rule statement settings. AWS WAF determines the location of requests using MaxMind GeoIP databases. MaxMind reports very high accuracy of their data at the country level, although accuracy varies according to factors such as country and type of IP. For more information about MaxMind, see [MaxMind IP Geolocation](https://support.maxmind.com/hc/en-us/sections/4407519834267-IP-Geolocation). If you think any of the GeoIP data is incorrect, you can submit a correction request to Maxmind at [MaxMind Correct GeoIP2 Data](https://support.maxmind.com/hc/en-us/articles/4408252036123-GeoIP-Correction). AWS WAF uses the alpha-2 country and region codes from the International Organization for Standardization (ISO) 3166 standard. You can find the codes at the following locations: + At the ISO website, you can search the country codes at [ISO Online Browsing Platform (OBP)](https://www.iso.org/obp/ui#home). + On Wikipedia, the country codes are listed at [ISO 3166-2](https://en.wikipedia.org/wiki/ISO_3166-2). The region codes for a country are listed at the URL `https://en.wikipedia.org/wiki/ISO_3166-2:`. For example, the regions for the United States are at [ISO 3166-2:US](https://en.wikipedia.org/wiki/ISO_3166-2:US) and for Ukraine they're at [ISO 3166-2:UA](https://en.wikipedia.org/wiki/ISO_3166-2:UA). 1. **Determines the country label and region label to add to the request** — The labels indicate whether the geo match statement uses the origin IP or a forwarded IP configuration. + **Origin IP** The country label is `awswaf:clientip:geo:country:`. Example for the United States: `awswaf:clientip:geo:country:US`. The region label is `awswaf:clientip:geo:region:-`. Example for Oregon in the United States: `awswaf:clientip:geo:region:US-OR`. + **Forwarded IP** The country label is `awswaf:forwardedip:geo:country:`. Example for the United States: `awswaf:forwardedip:geo:country:US`. The region label is `awswaf:forwardedip:geo:region:-`. Example for Oregon in the United States: `awswaf:forwardedip:geo:region:US-OR`. If the country or region code isn't available for a request's specified IP address, AWS WAF uses `XX` in the labels, in the place of the value. For example, the following label is for a client IP whose country code isn't available: `awswaf:clientip:geo:country:XX` and the following is for a forwarded IP whose country is the United States, but whose region code isn't available: `awswaf:forwardedip:geo:region:US-XX`. 1. **Evaluates the request's country code against the rule criteria** The geo match statement adds country and region labels to all requests that it inspects, regardless of whether it finds a match. **Note** AWS WAF adds any labels at the end of a rule's web request evaluation. Because of this, any label matching that you use against the labels from a geo match statement must be defined in a separate rule from the rule that contains the geo match statement. If you want to inspect only region values, you can write a geo match rule with Count action and with a single country code match, followed by a label match rule for the region labels. You are required to supply a country code for the geo match rule to evaluate, even for this approach. You can reduce logging and count metrics by specifying a country that's very unlikely to be a source of traffic to your site. ## CloudFront distributions and the CloudFront geo restriction feature For CloudFront distributions, if you use the CloudFront geo restriction feature, be aware that the feature doesn't forward blocked requests to AWS WAF. It does forward allowed requests to AWS WAF. If you want to block requests based on the geography plus other criteria that you can specify in AWS WAF, use the AWS WAF geo match statement and don't use the CloudFront geo restriction feature. ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs ** – 1 WCU. **Settings** – This statement uses the following settings: + **Country codes** – An array of country codes to compare for a geo match. These must be two-character country codes from the alpha-2 country ISO codes of the ISO 3166 international standard, for example, `["US","CN"]`. + **(Optional) Forwarded IP configuration** – By default, AWS WAF uses the IP address in the web request origin to determine country of origin. Alternatively, you can configure the rule to use a forwarded IP in an HTTP header like `X-Forwarded-For` instead. AWS WAF uses the first IP address in the header. With this configuration, you also specify a fallback behavior to apply to a web request with a malformed IP address in the header. The fallback behavior sets the matching result for the request, to match or no match. For more information, see [Using forwarded IP addresses](waf-rule-statement-forwarded-ip-address.md). ## Where to find this rule statement + **Rule builder** on the console – For **Request option**, choose **Originates from a country in**. + **API** – [GeoMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_GeoMatchStatement.html) ## Examples You can use the geo match statement to manage requests from specific countries or regions. For example, if you want to block requests from certain countries, but still allow requests from a specific set of IP addresses in those countries, you could create a rule with the action set to Block and the following nested statements, shown in pseudocode: + AND statement + Geo match statement listing the countries that you want to block + NOT statement + IP set statement that specifies the IP addresses that you want to allow through Or, if you want to block some regions in certain countries, but still allow requests from other regions in those countries, you could first define a geo match rule with the action set to Count. Then, define a label match rule that matches against the added geo match labels and handles the requests as you need. The following pseudo code describes an example of this approach: 1. Geo match statement listing the countries with regions that you want to block, but with the action set to Count. This labels every web request regardless of match status, and it also gives you count metrics for the countries of interest. 1. `AND` statement with Block action + Label match statement that specifies the labels for the countries that you want to block + `NOT` statement + Label match statement that specifies the labels of the regions in those countries that you want to allow through The following JSON listing shows an implementation of the two rules described in the prior pseudocode. These rules block all traffic from the United States except for traffic from Oregon and Washington. The geo match statement adds country and region labels to all requests that it inspects. The label match rule runs after the geo match rule, so it can match against the country and region labels that the geo match rule has just added. The geo match statement uses a forwarded IP address, so the label matching also specifies forwarded IP labels. ``` { "Name": "geoMatchForLabels", "Priority": 10, "Statement": { "GeoMatchStatement": { "CountryCodes": [ "US" ], "ForwardedIPConfig": { "HeaderName": "X-Forwarded-For", "FallbackBehavior": "MATCH" } } }, "Action": { "Count": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "geoMatchForLabels" } }, { "Name": "blockUSButNotOROrWA", "Priority": 11, "Statement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:forwardedip:geo:country:US" } }, { "NotStatement": { "Statement": { "OrStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:forwardedip:geo:region:US-OR" } }, { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:forwardedip:geo:region:US-WA" } } ] } } } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "blockUSButNotOROrWA" } } ``` As another example, you can combine geo matching with rate-based rules to prioritize resources for users in a particular country or region. You create a different rate-based statement for each geo match or label match statement that you use to differentiate your users. Set a higher rate limit for users in the preferred country or region and set a lower rate limit for other users. The following JSON listing shows a geo match rule followed by rate-based rules that limit the rate of traffic from the United States. The rules allow traffic from Oregon to come in at a higher rate than traffic from anywhere else in the country. ``` { "Name": "geoMatchForLabels", "Priority": 190, "Statement": { "GeoMatchStatement": { "CountryCodes": [ "US" ] } }, "Action": { "Count": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "geoMatchForLabels" } }, { "Name": "rateLimitOregon", "Priority": 195, "Statement": { "RateBasedStatement": { "Limit": 3000, "AggregateKeyType": "IP", "ScopeDownStatement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:clientip:geo:region:US-OR" } } } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "rateLimitOregon" } }, { "Name": "rateLimitUSNotOR", "Priority": 200, "Statement": { "RateBasedStatement": { "Limit": 100, "AggregateKeyType": "IP", "ScopeDownStatement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:clientip:geo:country:US" } }, { "NotStatement": { "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:clientip:geo:region:US-OR" } } } } ] } } } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "rateLimitUSNotOR" } } ``` # IP set match rule statement This section explains what an IP set match statement is and how it works. The IP set match statement inspects the IP address of a web request against a set of IP addresses and address ranges. Use this to allow or block web requests based on the IP addresses that the requests originate from. By default, AWS WAF uses the IP address from the web request origin, but you can configure the rule to use an HTTP header like `X-Forwarded-For` instead. AWS WAF supports all IPv4 and IPv6 CIDR ranges except for `/0`. For more information about CIDR notation, see the Wikipedia entry [Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing). An IP set can hold up to 10,000 IP addresses or IP address ranges to check. **Note** Each IP set match rule references an IP set, which you create and maintain independent of your rules. You can use a single IP set in multiple rules, and when you update the referenced set, AWS WAF automatically updates all rules that reference it. For information about creating and managing an IP set, see [Creating and managing an IP set in AWS WAF](waf-ip-set-managing.md). When you add or update the rules in your rule group or protection pack (web ACL), choose the option **IP set** and select the name of the IP set that you want to use. ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs** – 1 WCU for most. If you configure the statement to use forwarded IP addresses and specify a position of ANY, increase the WCU usage by 4. This statement uses the following settings: + **IP set specification** – Choose the IP set that you want to use from the list or create a new one. + **(Optional) Forwarded IP configuration** – An alternate forwarded IP header name to use in place of the request origin. You specify whether to match against the first, last, or any address in the header. You also specify a fallback behavior to apply to a web request with a malformed IP address in the specified header. The fallback behavior sets the matching result for the request, to match or no match. For more information, see [Using forwarded IP addresses](waf-rule-statement-forwarded-ip-address.md). ## Where to find this rule statement **Where to find this rule statement** + **Rule builder** on the console – For **Request option**, choose **Originates from an IP address in**. + **Add my own rules and rule groups** page on the console – Choose the **IP set** option. + **API** – [IPSetReferenceStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_IPSetReferenceStatement.html) # Autonomous System Number (ASN) match rule statement An ASN match rule statement in AWS WAF allows you to inspect web traffic based on the Autonomous System Number (ASN) associated with the request's IP address. ASNs are unique identifiers assigned to large internet networks managed by organizations such as internet service providers, enterprises, universities, or government agencies. By using ASN match statements, you can allow or block traffic from specific network organizations without having to manage individual IP addresses. This approach offers a more stable and efficient way to control access compared to IP-based rules, as ASNs change less frequently than IP ranges. ASN matching is particularly useful for scenarios such as blocking traffic from known problematic networks or allowing access only from trusted partner networks. The ASN match statement provides flexibility in determining the client IP address through optional forwarded IP configuration, making it compatible with various network setups including those using content delivery networks (CDNs) or reverse proxies. **Note** ASN matching supplements, but doesn't replace, standard authentication and authorization controls. We recommend that you implement authentication and authorization mechanisms, such as IAM, to verify the identity of all requests in your applications. ## How the ASN match statement works AWS WAF determines the ASN of a request based on its IP address. By default, AWS WAF uses the IP address of the web request's origin. You can configure AWS WAF to use an IP address from an alternate request header, like `X-Forwarded-For`, by enabling forwarded IP configuration in the rule statement settings. The ASN match statement compares the request's ASN against the list of ASNs specified in the rule. If the ASN matches one in the list, the statement evaluates to true, and the associated rule action is applied. ### Handling unmapped ASNs If AWS WAF cannot determine an ASN for a valid IP address, it assigns ASN 0. You can include ASN 0 in your rule to handle these cases explicitly. ### Fallback Behavior for Invalid IP Addresses When you configure the ASN match statement to use forwarded IP addresses, you can specify a fallback behavior of *Match* or *No match* for requests with invalid or missing IP addresses in the designated header. ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs** – 1 WCU This statement uses the following settings: + **ASN list** – An array of ASN numbers to compare for an ASN match. Valid values range from 0 to 4294967295. You can specify up to 100 ASNs for each rule. + **(Optional) Forwarded IP configuration** – By default, AWS WAF uses the IP address in the web request origin to determine the ASN. Alternatively, you can configure the rule to use a forwarded IP in an HTTP header like `X-Forwarded-For` instead. You specify whether to use the first, last, or any address in the header. With this configuration, you also specify a fallback behavior to apply to a web request with a malformed IP address in the header. The fallback behavior sets the matching result for the request, to match or no match. For more information, see [Using forwarded IP addresses](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-forwarded-ip-address.html). ## Where to find this rule statement + **Rule builder** on the console – For **Request option**, choose **Originates from ASN in**. + **API** – [AsnMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_AsnMatchStatement.html) ## Examples This example blocks requests originating from two specific ASNs derived from an `X-Forwarded-For` header. If the IP address in the header is malformed, the configured fallback behavior is `NO_MATCH`. ``` { "Action": { "Block": {} }, "Name": "AsnMatchStatementRule", "Priority": 1, "Statement": { "AsnMatchStatement": { "AsnList": [64496, 64500] }, "ForwardedIPConfig": { "FallbackBehavior": "NO_MATCH", "HeaderName": "X-Forwarded-For" } }, "VisibilityConfig": { "CloudWatchMetricsEnabled": true, "MetricName": "AsnMatchRuleMetrics", "SampledRequestsEnabled": true } }, "VisibilityConfig": { "CloudWatchMetricsEnabled": true, "MetricName": "WebAclMetrics", "SampledRequestsEnabled": true } } ``` # Label match rule statement This section explains what a label match statement is and how it works. The label match statement inspects the labels that are on the web request against a string specification. The labels that are available to a rule for inspection are those that have already been added to the web request by other rules in the same protection pack (web ACL) evaluation. Labels don't persist outside of the protection pack (web ACL) evaluation, but you can access label metrics in CloudWatch and you can see summaries of label information for any protection pack (web ACL) in the AWS WAF console. For more information, see [Label metrics and dimensions](waf-metrics.md#waf-metrics-label) and [Monitoring and tuning your AWS WAF protections](web-acl-testing-activities.md). You can also see labels in the logs. For information, see [Log fields for protection pack (web ACL) traffic](logging-fields.md). **Note** A label match statement can only see labels from rules that are evaluated earlier in the protection pack (web ACL). For information about how AWS WAF evaluates the rules and rule groups in a protection pack (web ACL), see [Setting rule priority](web-acl-processing-order.md). For more information about adding and matching labels, see [Web request labeling in AWS WAF](waf-labels.md). ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs** – 1 WCU This statement uses the following settings: + **Match scope** – Set this to **Label** to match against the label name and, optionally, the preceding namespaces and prefix. Set this to **Namespace** to match against some or all of the namespace specifications and, optionally, the preceding prefix. + **Key** – The string that you want to match against. If you specify a namespace match scope, this should only specify namespaces and optionally the prefix, with an ending colon. If you specify a label match scope, this must include the label name and can optionally include preceding namespaces and prefix. For more information about these settings, see [AWS WAF rules that match labels](waf-rule-label-match.md) and [AWS WAF label match examples](waf-rule-label-match-examples.md). ## Where to find this rule statement + **Rule builder** on the console – For **Request option**, choose **Has label**. + **API** – [LabelMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_LabelMatchStatement.html) # Regex match rule statement This section explains what a regex match statement is and how it works. A regex match statement instructs AWS WAF to match a request component against a single regular expression (regex). A web request matches the statement if the request component matches the regex that you specify. This statement type is a good alternative to the [Regex pattern set match rule statement](waf-rule-statement-type-regex-pattern-set-match.md) for situations where you want to combine your matching criteria using mathematical logic. For example, if you want a request component to match against some regex patterns and to not match against others, you can combine the regex match statements using the [AND rule statement](waf-rule-statement-type-and.md) and the [NOT rule statement](waf-rule-statement-type-not.md). AWS WAF supports the pattern syntax used by the PCRE library `libpcre` with some exceptions. The library is documented at [PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/). For information about AWS WAF support, see [Supported regular expression syntax in AWS WAF](waf-regex-pattern-support.md). ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs** – 3 WCUs, as a base cost. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. This statement type operates on a web request component, and requires the following request component settings: + **Request component** – The part of the web request to inspect, for example, a query string or the body. **Warning** If you inspect the request components **Body**, **JSON body**, **Headers**, or **Cookies**, read about the limitations on how much content AWS WAF can inspect at [Oversize web request components in AWS WAF](waf-oversize-request-components.md). For information about web request components, see [Adjusting rule statement settings in AWS WAF](waf-rule-statement-fields.md). + **Optional text transformations** – Transformations that you want AWS WAF to perform on the request component before inspecting it. For example, you could transform to lowercase or normalize white space. If you specify more than one transformation, AWS WAF processes them in the order listed. For information, see [Using text transformations in AWS WAF](waf-rule-statement-transformation.md). ## Where to find this rule statement + **Rule builder** on the console – For **Match type**, choose **Matches regular expression**. + **API** – [RegexMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_RegexMatchStatement.html) # Regex pattern set match rule statement This section explains what a regex pattern set match statement is and how it works. The regex pattern set match inspects the part of the web request that you specify for the regular expression patterns that you've specified inside a regex pattern set. AWS WAF supports the pattern syntax used by the PCRE library `libpcre` with some exceptions. The library is documented at [PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/). For information about AWS WAF support, see [Supported regular expression syntax in AWS WAF](waf-regex-pattern-support.md). **Note** Each regex pattern set match rule references a regex pattern set, which you create and maintain independent of your rules. You can use a single regex pattern set in multiple rules, and when you update the referenced set, AWS WAF automatically updates all rules that reference it. For information about creating and managing a regex pattern set, see [Creating and managing a regex pattern set in AWS WAF](waf-regex-pattern-set-managing.md). A regex pattern set match statement instructs AWS WAF to search for any of the patterns in the set inside the request component that you choose. A web request will match the pattern set rule statement if the request component matches any of the patterns in the set. If you want to combine your regex pattern matches using logic, for example to match against some regular expressions and not match against others, consider using [Regex match rule statement](waf-rule-statement-type-regex-match.md). ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs** – 25 WCUs, as a base cost. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. This statement type operates on a web request component, and requires the following request component settings: + **Request component** – The part of the web request to inspect, for example, a query string or the body. **Warning** If you inspect the request components **Body**, **JSON body**, **Headers**, or **Cookies**, read about the limitations on how much content AWS WAF can inspect at [Oversize web request components in AWS WAF](waf-oversize-request-components.md). For information about web request components, see [Adjusting rule statement settings in AWS WAF](waf-rule-statement-fields.md). + **Optional text transformations** – Transformations that you want AWS WAF to perform on the request component before inspecting it. For example, you could transform to lowercase or normalize white space. If you specify more than one transformation, AWS WAF processes them in the order listed. For information, see [Using text transformations in AWS WAF](waf-rule-statement-transformation.md). This statement requires the following settings: + Regex pattern set specification – Choose the regex pattern set that you want to use from the list or create a new one. ## Where to find this rule statement + **Rule builder** on the console – For **Match type**, choose **String match condition** > **Matches pattern from regular expression set**. + **API** – [RegexPatternSetReferenceStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_RegexPatternSetReferenceStatement.html) # Size constraint rule statement This section explains what a size constraint statement is and how it works. A size constraint statement compares the number of bytes that AWS WAF receives for a web request component to a number that you provide, and matches according to your comparison criteria. The comparison criteria is an operator such as greater than (>) or less than (<). For example, you can match on requests that have a query string with a size that's greater than 100 bytes. If you inspect the URI path, any `/` in the path counts as one character. For example, the URI path `/logo.jpg` is nine characters long. **Note** This statement only inspects the size of the web request component. It doesn't inspect the contents of the component. ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs** – 1 WCU, as a base cost. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. This statement type operates on a web request component, and requires the following request component settings: + **Request component** – The part of the web request to inspect, for example, a query string or the body. For information about web request components, see [Adjusting rule statement settings in AWS WAF](waf-rule-statement-fields.md). A size constraint statement inspects only the size of the component after any transformations have been applied. It does not inspect the contents of the component. + **Optional text transformations** – Transformations that you want AWS WAF to perform on the request component before inspecting its size. For example, you could compress white space or decode HTML entities. If you specify more than one transformation, AWS WAF processes them in the order listed. For information, see [Using text transformations in AWS WAF](waf-rule-statement-transformation.md). Additionally, this statement requires the following settings: + **Size match condition** – This indicates the numerical comparison operator to use to compare the size that you provide with the request component that you've chosen. Choose the operator from the list. + **Size** – The size setting, in bytes, to use in the comparison. ## Where to find this rule statement + **Rule builder** on the console – For **Match type**, under **Size match condition**, choose the condition that you want to use. + **API** – [SizeConstraintStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_SizeConstraintStatement.html) # SQL injection attack rule statement This section explains what a SQL injection rule statement is and how it works. An SQL injection rule statement inspects for malicious SQL code. Attackers insert malicious SQL code into web requests in order to do things like modify your database or extract data from it. ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs** – The base cost depends on the sensitivity level setting for the rule statement: Low costs 20 and High costs 30. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. This statement type operates on a web request component, and requires the following request component settings: + **Request component** – The part of the web request to inspect, for example, a query string or the body. **Warning** If you inspect the request components **Body**, **JSON body**, **Headers**, or **Cookies**, read about the limitations on how much content AWS WAF can inspect at [Oversize web request components in AWS WAF](waf-oversize-request-components.md). For information about web request components, see [Adjusting rule statement settings in AWS WAF](waf-rule-statement-fields.md). + **Optional text transformations** – Transformations that you want AWS WAF to perform on the request component before inspecting it. For example, you could transform to lowercase or normalize white space. If you specify more than one transformation, AWS WAF processes them in the order listed. For information, see [Using text transformations in AWS WAF](waf-rule-statement-transformation.md). Additionally, this statement requires the following setting: + **Sensitivity level** – This setting tunes the sensitivity of the SQL injection match criteria. The options are LOW and HIGH. The default setting is LOW. The HIGH setting detects more SQL injection attacks, and is the recommended setting. Due to the higher sensitivity, this setting generates more false positives, especially if your web requests typically contain unusual strings. During your protection pack (web ACL) testing and tuning, you might need to do more work to mitigate false positives. For information, see [Testing and tuning your AWS WAF protections](web-acl-testing.md). The lower setting provides less stringent SQL injection detection, which also results in fewer false positives. LOW can be a better choice for resources that have other protections against SQL injection attacks or that have a low tolerance for false positives. ## Where to find this rule statement + **Rule builder** on the console – For **Match type**, choose **Attack match condition** > **Contains SQL injection attacks**. + **API** – [SqliMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_SqliMatchStatement.html) # String match rule statement This section explains what a string match statement is and how it works. A string match statement indicates the string that you want AWS WAF to search for in a request, where in the request to search, and how. For example, you can look for a specific string at the start of any query string in the request or as an exact match for the request's `User-agent` header. Usually, the string consists of printable ASCII characters, but you can use any character from hexadecimal 0x00 to 0xFF (decimal 0 to 255). ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs** – The base cost depends on the type of match that you use. + **Exactly matches string** – 2 + **Starts with string** – 2 + **Ends with string** – 2 + **Contains string** – 10 + **Contains word** – 10 If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. This statement type operates on a web request component, and requires the following request component settings: + **Request component** – The part of the web request to inspect, for example, a query string or the body. **Warning** If you inspect the request components **Body**, **JSON body**, **Headers**, or **Cookies**, read about the limitations on how much content AWS WAF can inspect at [Oversize web request components in AWS WAF](waf-oversize-request-components.md). For information about web request components, see [Adjusting rule statement settings in AWS WAF](waf-rule-statement-fields.md). + **Optional text transformations** – Transformations that you want AWS WAF to perform on the request component before inspecting it. For example, you could transform to lowercase or normalize white space. If you specify more than one transformation, AWS WAF processes them in the order listed. For information, see [Using text transformations in AWS WAF](waf-rule-statement-transformation.md). Additionally, this statement requires the following settings: + **String to match** – This is the string that you want AWS WAF to compare to the specified request component. Usually, the string consists of printable ASCII characters, but you can use any character from hexadecimal 0x00 to 0xFF (decimal 0 to 255). + **String match condition** – This indicates the search type that you want AWS WAF to perform. + **Exactly matches string** – The string and the value of the request component are identical. + **Starts with string** – The string appears at the beginning of the request component. + **Ends with string** – The string appears at the end of the request component. + **Contains string** – The string appears anywhere in the request component. + **Contains word** – The string that you specify must appear in the request component. For this option, the string that you specify must contain only alphanumeric characters or underscore (A-Z, a-z, 0-9, or \$1). One of the following must be true for the request to match: + The string exactly matches the value of the request component, such as the value of a header. + The string is at the beginning of the request component and is followed by a character other than an alphanumeric character or underscore (\$1), for example, `BadBot;`. + The string is at the end of the request component and is preceded by a character other than an alphanumeric character or underscore (\$1), for example, `;BadBot`. + The string is in the middle of the request component and is preceded and followed by characters other than alphanumeric characters or underscore (\$1), for example, `-BadBot;`. ## Where to find this rule statement + **Rule builder** on the console – For **Match type**, choose **String match condition**, and then fill in the strings that you want to match against. + **API** – [ByteMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_ByteMatchStatement.html) # Cross-site scripting attack rule statement This section explains what an XSS (cross-site scripting) attack statement is and how it works. An XSS attack statement inspects for malicious scripts in a web request component. In an XSS attack, the attacker uses vulnerabilities in a benign website as a vehicle to inject malicious client-site scripts into other legitimate web browsers. ## Rule statement characteristics **Nestable** – You can nest this statement type. **WCUs** – 40 WCUs, as a base cost. If you use the request component **All query parameters**, add 10 WCUs. If you use the request component **JSON body**, double the base cost WCUs. For each **Text transformation** that you apply, add 10 WCUs. This statement type operates on a web request component, and requires the following request component settings: + **Request component** – The part of the web request to inspect, for example, a query string or the body. **Warning** If you inspect the request components **Body**, **JSON body**, **Headers**, or **Cookies**, read about the limitations on how much content AWS WAF can inspect at [Oversize web request components in AWS WAF](waf-oversize-request-components.md). For information about web request components, see [Adjusting rule statement settings in AWS WAF](waf-rule-statement-fields.md). + **Optional text transformations** – Transformations that you want AWS WAF to perform on the request component before inspecting it. For example, you could transform to lowercase or normalize white space. If you specify more than one transformation, AWS WAF processes them in the order listed. For information, see [Using text transformations in AWS WAF](waf-rule-statement-transformation.md). ## Where to find this rule statement + **Rule builder** on the console – For **Match type**, choose **Attack match condition** > **Contains XSS injection attacks**. + **API** – [XssMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_XssMatchStatement.html)