This page is not yet available in Spanish. We are working on its translation.
If you have any questions or feedback about our current translation project,
feel free to reach out to us!aws_wafv2_acl
account_id
Type: STRING
application_integration_url
Type: STRING
Provider name: ApplicationIntegrationURL
Description: The URL to use in SDK integrations with Amazon Web Services managed rule groups. For example, you can use the integration SDKs with the account takeover prevention managed rule group AWSManagedRulesATPRuleSet
and the account creation fraud prevention managed rule group AWSManagedRulesACFPRuleSet
. This is only populated if you are using a rule group in your web ACL that integrates with your applications in this way. For more information, see WAF client application integration in the WAF Developer Guide.
arn
Type: STRING
Provider name: ARN
Description: The Amazon Resource Name (ARN) of the entity.
description
Type: STRING
Provider name: Description
Description: A description of the web ACL that helps with identification.
id
Type: STRING
Provider name: Id
Description: The unique identifier for the web ACL. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
lock_token
Type: STRING
Provider name: LockToken
Description: A token used for optimistic locking. WAF returns a token to your get
and list
requests, to mark the state of the entity at the time of the request. To make changes to the entity associated with the token, you provide the token to operations like update
and delete
. WAF uses the token to ensure that no changes have been made to the entity since you last retrieved it. If a change has been made, the update fails with a WAFOptimisticLockException
. If this happens, perform another get
, and use the new token returned by that operation.
logging_configuration
Type: STRUCT
Provider name: LoggingConfiguration
Description: The LoggingConfiguration for the specified web ACL.
log_destination_configs
Type: UNORDERED_LIST_STRING
Provider name: LogDestinationConfigs
Description: The logging destination configuration that you want to associate with the web ACL. You can associate one logging destination to a web ACL.
log_scope
Type: STRING
Provider name: LogScope
Description: The owner of the logging configuration, which must be set to CUSTOMER
for the configurations that you manage. The log scope SECURITY_LAKE
indicates a configuration that is managed through Amazon Security Lake. You can use Security Lake to collect log and event data from various sources for normalization, analysis, and management. For information, see Collecting data from Amazon Web Services services in the Amazon Security Lake user guide.
Default: CUSTOMER
log_type
Type: STRING
Provider name: LogType
Description: Used to distinguish between various logging options. Currently, there is one option.
Default: WAF_LOGS
logging_filter
Type: STRUCT
Provider name: LoggingFilter
Description: Filtering that specifies which web requests are kept in the logs and which are dropped. You can filter on the rule action and on the web request labels that were applied by matching rules during web ACL evaluation.
default_behavior
Type: STRING
Provider name: DefaultBehavior
Description: Default handling for logs that don’t match any of the specified filtering conditions.
filters
Type: UNORDERED_LIST_STRUCT
Provider name: Filters
Description: The filters that you want to apply to the logs.
behavior
Type: STRING
Provider name: Behavior
Description: How to handle logs that satisfy the filter’s conditions and requirement.
conditions
Type: UNORDERED_LIST_STRUCT
Provider name: Conditions
Description: Match conditions for the filter.
action_condition
Type: STRUCT
Provider name: ActionCondition
Description: A single action condition. This is the action setting that a log record must contain in order to meet the condition.
action
Type: STRING
Provider name: Action
Description: The action setting that a log record must contain in order to meet the condition. This is the action that WAF applied to the web request. For rule groups, this is either the configured rule action setting, or if you’ve applied a rule action override to the rule, it’s the override action. The value EXCLUDED_AS_COUNT
matches on excluded rules and also on rules that have a rule action override of Count.
label_name_condition
Type: STRUCT
Provider name: LabelNameCondition
Description: A single label name condition. This is the fully qualified label name that a log record must contain in order to meet the condition. Fully qualified labels have a prefix, optional namespaces, and label name. The prefix identifies the rule group or web ACL context of the rule that added the label.
label_name
Type: STRING
Provider name: LabelName
Description: The label name that a log record must contain in order to meet the condition. This must be a fully qualified label name. Fully qualified labels have a prefix, optional namespaces, and label name. The prefix identifies the rule group or web ACL context of the rule that added the label.
requirement
Type: STRING
Provider name: Requirement
Description: Logic to apply to the filtering conditions. You can specify that, in order to satisfy the filter, a log must match all conditions or must match at least one condition.
managed_by_firewall_manager
Type: BOOLEAN
Provider name: ManagedByFirewallManager
Description: Indicates whether the logging configuration was created by Firewall Manager, as part of an WAF policy configuration. If true, only Firewall Manager can modify or delete the configuration.
redacted_fields
Type: UNORDERED_LIST_STRUCT
Provider name: RedactedFields
Description: The parts of the request that you want to keep out of the logs. For example, if you redact the SingleHeader
field, the HEADER
field in the logs will be REDACTED
for all rules that use the SingleHeader
FieldToMatch
setting. Redaction applies only to the component that’s specified in the rule’s FieldToMatch
setting, so the SingleHeader
redaction doesn’t apply to rules that use the Headers
FieldToMatch
. You can specify only the following fields for redaction: UriPath
, QueryString
, SingleHeader
, and Method
. This setting has no impact on request sampling. With request sampling, the only way to exclude fields is by disabling sampling in the web ACL visibility configuration.
all_query_arguments
Type: STRUCT
Provider name: AllQueryArguments
Description: Inspect all query arguments.
body
Type: STRUCT
Provider name: Body
Description: Inspect the request body as plain text. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the Body
object configuration.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
cookies
Type: STRUCT
Provider name: Cookies
Description: Inspect the request cookies. You must configure scope and pattern matching filters in the Cookies
object, to define the set of cookies and the parts of the cookies that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s cookies and only the first 200 cookies are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize cookie content in the Cookies
object. WAF applies the pattern matching filters to the cookies that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of cookies to inspect in a web request. You must specify exactly one setting: either All
, IncludedCookies
, or ExcludedCookies
. Example JSON: “MatchPattern”: { “IncludedCookies”: [ “session-id-time”, “session-id” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all cookies.
excluded_cookies
Type: UNORDERED_LIST_STRING
Provider name: ExcludedCookies
Description: Inspect only the cookies whose keys don’t match any of the strings specified here.
included_cookies
Type: UNORDERED_LIST_STRING
Provider name: IncludedCookies
Description: Inspect only the cookies that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the cookies to inspect with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the cookies of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request cookies when they exceed 8 KB (8192 bytes) or 200 total cookies. The underlying host service forwards a maximum of 200 cookies and at most 8 KB of cookie contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available cookies normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
header_order
Type: STRUCT
Provider name: HeaderOrder
Description: Inspect a string containing the list of the request’s header names, ordered as they appear in the web request that WAF receives for inspection. WAF generates the string and then uses that as the field to match component in its inspection. WAF separates the header names in the string using colons and no added spaces, for example host:user-agent:accept:authorization:referer
.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
headers
Type: STRUCT
Provider name: Headers
Description: Inspect the request headers. You must configure scope and pattern matching filters in the Headers
object, to define the set of headers to and the parts of the headers that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s headers and only the first 200 headers are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize header content in the Headers
object. WAF applies the pattern matching filters to the headers that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of headers to inspect in a web request. You must specify exactly one setting: either All
, IncludedHeaders
, or ExcludedHeaders
. Example JSON: “MatchPattern”: { “ExcludedHeaders”: [ “KeyToExclude1”, “KeyToExclude2” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all headers.
excluded_headers
Type: UNORDERED_LIST_STRING
Provider name: ExcludedHeaders
Description: Inspect only the headers whose keys don’t match any of the strings specified here.
included_headers
Type: UNORDERED_LIST_STRING
Provider name: IncludedHeaders
Description: Inspect only the headers that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the headers to match with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
ja3_fingerprint
Type: STRUCT
Provider name: JA3Fingerprint
Description: Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request’s JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client’s TLS configuration. WAF calculates and logs this fingerprint for each request that has enough TLS Client Hello information for the calculation. Almost all web requests include this information. You can use this choice only with a string match ByteMatchStatement
with the PositionalConstraint
set to EXACTLY
. You can obtain the JA3 fingerprint for client requests from the web ACL logs. If WAF is able to calculate the fingerprint, it includes it in the logs. For information about the logging fields, see Log fields in the WAF Developer Guide. Provide the JA3 fingerprint string from the logs in your string match statement specification, to match with any future requests that have the same TLS configuration.
fallback_behavior
Type: STRING
Provider name: FallbackBehavior
Description: The match status to assign to the web request if the request doesn’t have a JA3 fingerprint. You can specify the following fallback behaviors:MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
json_body
Type: STRUCT
Provider name: JsonBody
Description: Inspect the request body as JSON. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the JsonBody
object configuration.
invalid_fallback_behavior
Type: STRING
Provider name: InvalidFallbackBehavior
Description: What WAF should do if it fails to completely parse the JSON body. The options are the following:EVALUATE_AS_STRING
- Inspect the body as plain text. WAF applies the text transformations and inspection criteria that you defined for the JSON inspection to the body text string.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
If you don’t provide this setting, WAF parses and evaluates the content only up to the first parsing failure that it encounters. WAF parsing doesn’t fully validate the input JSON string, so parsing can succeed even for invalid JSON. When parsing succeeds, WAF doesn’t apply the fallback behavior. For more information, see JSON body in the WAF Developer Guide.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
all
Type: STRUCT
Provider name: All
Description: Match all of the elements. See also MatchScope
in JsonBody. You must specify either this setting or the IncludedPaths
setting, but not both.
included_paths
Type: UNORDERED_LIST_STRING
Provider name: IncludedPaths
Description: Match only the specified include paths. See also MatchScope
in JsonBody. Provide the include paths using JSON Pointer syntax. For example, “IncludedPaths”: ["/dogs/0/name", “/dogs/1/name”]
. For information about this syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. You must specify either this setting or the All
setting, but not both. Don’t use this option to include all paths. Instead, use the All
setting.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the JSON to match against using the MatchPattern
. If you specify ALL
, WAF matches against keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
method
Type: STRUCT
Provider name: Method
Description: Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
query_string
Type: STRUCT
Provider name: QueryString
Description: Inspect the query string. This is the part of a URL that appears after a ?
character, if any.
single_header
Type: STRUCT
Provider name: SingleHeader
Description: Inspect a single header. Provide the name of the header to inspect, for example, User-Agent
or Referer
. This setting isn’t case sensitive. Example JSON: “SingleHeader”: { “Name”: “haystack” }
Alternately, you can filter and inspect all headers with the Headers
FieldToMatch
setting.
name
Type: STRING
Provider name: Name
Description: The name of the query header to inspect.
single_query_argument
Type: STRUCT
Provider name: SingleQueryArgument
Description: Inspect a single query argument. Provide the name of the query argument to inspect, such as UserName or SalesRegion. The name can be up to 30 characters long and isn’t case sensitive. Example JSON: “SingleQueryArgument”: { “Name”: “myArgument” }
name
Type: STRING
Provider name: Name
Description: The name of the query argument to inspect.
uri_path
Type: STRUCT
Provider name: UriPath
Description: Inspect the request URI path. This is the part of the web request that identifies a resource, for example, /images/daily-ad.jpg
.
resource_arn
Type: STRING
Provider name: ResourceArn
Description: The Amazon Resource Name (ARN) of the web ACL that you want to associate with LogDestinationConfigs
.
name
Type: STRING
Provider name: Name
Description: The name of the web ACL. You cannot change the name of a web ACL after you create it.
resource_arns
Type: UNORDERED_LIST_STRING
Provider name: ResourceArns
Description: The array of Amazon Resource Names (ARNs) of the associated resources.
Type: UNORDERED_LIST_STRING
web_acl
Type: STRUCT
Provider name: WebACL
Description: The web ACL specification. You can modify the settings in this web ACL and use it to update this web ACL or create a new one.
arn
Type: STRING
Provider name: ARN
Description: The Amazon Resource Name (ARN) of the web ACL that you want to associate with the resource.
association_config
Type: STRUCT
Provider name: AssociationConfig
Description: Specifies custom configurations for the associations between the web ACL and protected resources. Use this to customize the maximum size of the request body that your protected resources forward to WAF for inspection. You can customize this setting for CloudFront, API Gateway, Amazon Cognito, App Runner, or Verified Access resources. The default setting is 16 KB (16,384 bytes). You are charged additional fees when your protected resources forward body sizes that are larger than the default. For more information, see WAF Pricing. For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
request_body
Type: STRING
Provider name: RequestBody
Description: Customizes the maximum size of the request body that your protected CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access resources forward to WAF for inspection. The default size is 16 KB (16,384 bytes). You can change the setting for any of the available resource types. You are charged additional fees when your protected resources forward body sizes that are larger than the default. For more information, see WAF Pricing. Example JSON: { “API_GATEWAY”: “KB_48”, “APP_RUNNER_SERVICE”: “KB_32” }
For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
capacity
Type: INT64
Provider name: Capacity
Description: The web ACL capacity units (WCUs) currently being used by this web ACL. WAF uses WCUs to calculate and control the operating resources that are used to run your rules, rule groups, and web ACLs. WAF calculates capacity differently for each rule type, to reflect the relative cost of each rule. Simple rules that cost little to run use fewer WCUs than more complex rules that use more processing power. Rule group capacity is fixed at creation, which helps users plan their web ACL WCU usage when they use a rule group. For more information, see WAF web ACL capacity units (WCU) in the WAF Developer Guide.
captcha_config
Type: STRUCT
Provider name: CaptchaConfig
Description: Specifies how WAF should handle CAPTCHA
evaluations for rules that don’t have their own CaptchaConfig
settings. If you don’t specify this, WAF uses its default settings for CaptchaConfig
.
immunity_time_property
Type: STRUCT
Provider name: ImmunityTimeProperty
Description: Determines how long a CAPTCHA
timestamp in the token remains valid after the client successfully solves a CAPTCHA
puzzle.
immunity_time
Type: INT64
Provider name: ImmunityTime
Description: The amount of time, in seconds, that a CAPTCHA
or challenge timestamp is considered valid by WAF. The default setting is 300. For the Challenge action, the minimum setting is 300.
challenge_config
Type: STRUCT
Provider name: ChallengeConfig
Description: Specifies how WAF should handle challenge evaluations for rules that don’t have their own ChallengeConfig
settings. If you don’t specify this, WAF uses its default settings for ChallengeConfig
.
immunity_time_property
Type: STRUCT
Provider name: ImmunityTimeProperty
Description: Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
immunity_time
Type: INT64
Provider name: ImmunityTime
Description: The amount of time, in seconds, that a CAPTCHA
or challenge timestamp is considered valid by WAF. The default setting is 300. For the Challenge action, the minimum setting is 300.
custom_response_bodies
Type: STRING
Provider name: CustomResponseBodies
Description: A map of custom response keys and content bodies. When you create a rule with a block action, you can send a custom response to the web request. You define these for the web ACL, and then use them in the rules and default actions that you define in the web ACL. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
default_action
Type: STRUCT
Provider name: DefaultAction
Description: The action to perform if none of the Rules
contained in the WebACL
match.
allow
Type: STRUCT
Provider name: Allow
Description: Specifies that WAF should allow requests by default.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
block
Type: STRUCT
Provider name: Block
Description: Specifies that WAF should block requests by default.
custom_response
Type: STRUCT
Provider name: CustomResponse
Description: Defines a custom response for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
custom_response_body_key
Type: STRING
Provider name: CustomResponseBodyKey
Description: References the response body that you want WAF to return to the web request client. You can define a custom response for a rule action or a default web ACL action that is set to block. To do this, you first define the response body key and value in the CustomResponseBodies
setting for the WebACL or RuleGroup where you want to use it. Then, in the rule action or web ACL default action BlockAction
setting, you reference the response body using this key.
response_code
Type: INT32
Provider name: ResponseCode
Description: The HTTP status code to return to the client. For a list of status codes that you can use in your custom responses, see Supported status codes for custom response in the WAF Developer Guide.
response_headers
Type: UNORDERED_LIST_STRUCT
Provider name: ResponseHeaders
Description: The HTTP headers to use in the response. You can specify any header name except for content-type
. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
description
Type: STRING
Provider name: Description
Description: A description of the web ACL that helps with identification.
id
Type: STRING
Provider name: Id
Description: A unique identifier for the WebACL
. This ID is returned in the responses to create and list commands. You use this ID to do things like get, update, and delete a WebACL
.
label_namespace
Type: STRING
Provider name: LabelNamespace
Description: The label namespace prefix for this web ACL. All labels added by rules in this web ACL have this prefix.- The syntax for the label namespace prefix for a web ACL is the following:
awswaf:<account ID>:webacl:<web ACL name>:
- When a rule with a label matches a web request, WAF adds the fully qualified label to the request. A fully qualified label is made up of the label namespace from the rule group or web ACL where the rule is defined and the label from the rule, separated by a colon:
<label namespace>:<label from rule>
managed_by_firewall_manager
Type: BOOLEAN
Provider name: ManagedByFirewallManager
Description: Indicates whether this web ACL is managed by Firewall Manager. If true, then only Firewall Manager can delete the web ACL or any Firewall Manager rule groups in the web ACL.
name
Type: STRING
Provider name: Name
Description: The name of the web ACL. You cannot change the name of a web ACL after you create it.
post_process_firewall_manager_rule_groups
Type: UNORDERED_LIST_STRUCT
Provider name: PostProcessFirewallManagerRuleGroups
Description: The last set of rules for WAF to process in the web ACL. This is defined in an Firewall Manager WAF policy and contains only rule group references. You can’t alter these. Any rules and rule groups that you define for the web ACL are prioritized before these. In the Firewall Manager WAF policy, the Firewall Manager administrator can define a set of rule groups to run first in the web ACL and a set of rule groups to run last. Within each set, the administrator prioritizes the rule groups, to determine their relative processing order.
firewall_manager_statement
Type: STRUCT
Provider name: FirewallManagerStatement
Description: The processing guidance for an Firewall Manager rule. This is like a regular rule Statement, but it can only contain a rule group reference.
managed_rule_group_statement
Type: STRUCT
Provider name: ManagedRuleGroupStatement
Description: A statement used by Firewall Manager to run the rules that are defined in a managed rule group. This is managed by Firewall Manager for an Firewall Manager WAF policy.
excluded_rules
Type: UNORDERED_LIST_STRUCT
Provider name: ExcludedRules
Description: Rules in the referenced rule group whose actions are set to Count
. Instead of this option, use RuleActionOverrides
. It accepts any valid action setting, including Count
.
name
Type: STRING
Provider name: Name
Description: The name of the rule whose action you want to override to Count
.
managed_rule_group_configs
Type: UNORDERED_LIST_STRUCT
Provider name: ManagedRuleGroupConfigs
Description: Additional information that’s used by a managed rule group. Many managed rule groups don’t require this. The rule groups used for intelligent threat mitigation require additional configuration:- Use the
AWSManagedRulesACFPRuleSet
configuration object to configure the account creation fraud prevention managed rule group. The configuration includes the registration and sign-up pages of your application and the locations in the account creation request payload of data, such as the user email and phone number fields. - Use the
AWSManagedRulesATPRuleSet
configuration object to configure the account takeover prevention managed rule group. The configuration includes the sign-in page of your application and the locations in the login request payload of data such as the username and password. - Use the
AWSManagedRulesBotControlRuleSet
configuration object to configure the protection level that you want the Bot Control rule group to use.
aws_managed_rules_acfp_rule_set
Type: STRUCT
Provider name: AWSManagedRulesACFPRuleSet
Description: Additional configuration for using the account creation fraud prevention (ACFP) managed rule group, AWSManagedRulesACFPRuleSet
. Use this to provide account creation request information to the rule group. For web ACLs that protect CloudFront distributions, use this to also provide the information about how your distribution responds to account creation requests. For information about using the ACFP managed rule group, see WAF Fraud Control account creation fraud prevention (ACFP) rule group and WAF Fraud Control account creation fraud prevention (ACFP) in the WAF Developer Guide.
creation_path
Type: STRING
Provider name: CreationPath
Description: The path of the account creation endpoint for your application. This is the page on your website that accepts the completed registration form for a new user. This page must accept POST
requests. For example, for the URL https://example.com/web/newaccount
, you would provide the path /web/newaccount
. Account creation page paths that start with the path that you provide are considered a match. For example /web/newaccount
matches the account creation paths /web/newaccount
, /web/newaccount/
, /web/newaccountPage
, and /web/newaccount/thisPage
, but doesn’t match the path /home/web/newaccount
or /website/newaccount
.
enable_regex_in_path
Type: BOOLEAN
Provider name: EnableRegexInPath
Description: Allow the use of regular expressions in the registration page path and the account creation path.
registration_page_path
Type: STRING
Provider name: RegistrationPagePath
Description: The path of the account registration endpoint for your application. This is the page on your website that presents the registration form to new users. This page must accept GET
text/html requests. For example, for the URL https://example.com/web/registration
, you would provide the path /web/registration
. Registration page paths that start with the path that you provide are considered a match. For example /web/registration
matches the registration paths /web/registration
, /web/registration/
, /web/registrationPage
, and /web/registration/thisPage
, but doesn’t match the path /home/web/registration
or /website/registration
.
request_inspection
Type: STRUCT
Provider name: RequestInspection
Description: The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
address_fields
Type: UNORDERED_LIST_STRUCT
Provider name: AddressFields
Description: The names of the fields in the request payload that contain your customer’s primary physical address. Order the address fields in the array exactly as they are ordered in the request payload. How you specify the address fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryaddressline1”: “THE_ADDRESS1”, “primaryaddressline2”: “THE_ADDRESS2”, “primaryaddressline3”: “THE_ADDRESS3” } }
, the address field idenfiers are /form/primaryaddressline1
, /form/primaryaddressline2
, and /form/primaryaddressline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
, the address fields identifiers are primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of a single primary address field. How you specify the address fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryaddressline1”: “THE_ADDRESS1”, “primaryaddressline2”: “THE_ADDRESS2”, “primaryaddressline3”: “THE_ADDRESS3” } }
, the address field idenfiers are /form/primaryaddressline1
, /form/primaryaddressline2
, and /form/primaryaddressline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
, the address fields identifiers are primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
.
email_field
Type: STRUCT
Provider name: EmailField
Description: The name of the field in the request payload that contains your customer’s email. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “email”: “THE_EMAIL” } }
, the email field specification is /form/email
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
email1
, the email field specification is email1
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the email field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “email”: “THE_EMAIL” } }
, the email field specification is /form/email
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
email1
, the email field specification is email1
.
password_field
Type: STRUCT
Provider name: PasswordField
Description: The name of the field in the request payload that contains your customer’s password. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the password field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
payload_type
Type: STRING
Provider name: PayloadType
Description: The payload type for your account creation endpoint, either JSON or form encoded.
phone_number_fields
Type: UNORDERED_LIST_STRUCT
Provider name: PhoneNumberFields
Description: The names of the fields in the request payload that contain your customer’s primary phone number. Order the phone number fields in the array exactly as they are ordered in the request payload. How you specify the phone number fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryphoneline1”: “THE_PHONE1”, “primaryphoneline2”: “THE_PHONE2”, “primaryphoneline3”: “THE_PHONE3” } }
, the phone number field identifiers are /form/primaryphoneline1
, /form/primaryphoneline2
, and /form/primaryphoneline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
, the phone number field identifiers are primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of a single primary phone number field. How you specify the phone number fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryphoneline1”: “THE_PHONE1”, “primaryphoneline2”: “THE_PHONE2”, “primaryphoneline3”: “THE_PHONE3” } }
, the phone number field identifiers are /form/primaryphoneline1
, /form/primaryphoneline2
, and /form/primaryphoneline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
, the phone number field identifiers are primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
.
username_field
Type: STRUCT
Provider name: UsernameField
Description: The name of the field in the request payload that contains your customer’s username. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
identifier
Type: STRING
Provider name: Identifier
Description: The name of the username field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
response_inspection
Type: STRUCT
Provider name: ResponseInspection
Description: The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates. Response inspection is available only in web ACLs that protect Amazon CloudFront distributions. The ACFP rule group evaluates the responses that your protected resources send back to client account creation attempts, keeping count of successful and failed attempts from each IP address and client session. Using this information, the rule group labels and mitigates requests from client sessions and IP addresses that have had too many successful account creation attempts in a short amount of time.
body_contains
Type: STRUCT
Provider name: BodyContains
Description: Configures inspection of the response body for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response body.
failure_strings
Type: UNORDERED_LIST_STRING
Provider name: FailureStrings
Description: Strings in the body of the response that indicate a failed login or account creation attempt. To be counted as a failure, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON example: “FailureStrings”: [ “Request failed” ]
success_strings
Type: UNORDERED_LIST_STRING
Provider name: SuccessStrings
Description: Strings in the body of the response that indicate a successful login or account creation attempt. To be counted as a success, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON examples: “SuccessStrings”: [ “Login successful” ]
and “SuccessStrings”: [ “Account creation successful”, “Welcome to our site!” ]
header
Type: STRUCT
Provider name: Header
Description: Configures inspection of the response header for success and failure indicators.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values in the response header with the specified name that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “FailureValues”: [ “LoginFailed”, “Failed login” ]
and “FailureValues”: [ “AccountCreationFailed” ]
name
Type: STRING
Provider name: Name
Description: The name of the header to match against. The name must be an exact match, including case. JSON example: “Name”: [ “RequestResult” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values in the response header with the specified name that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “SuccessValues”: [ “LoginPassed”, “Successful login” ]
and “SuccessValues”: [ “AccountCreated”, “Successful account creation” ]
json
Type: STRUCT
Provider name: Json
Description: Configures inspection of the response JSON for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response JSON.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values for the specified identifier in the response JSON that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “FailureValues”: [ “False”, “Failed” ]
identifier
Type: STRING
Provider name: Identifier
Description: The identifier for the value to match against in the JSON. The identifier must be an exact match, including case. JSON examples: “Identifier”: [ “/login/success” ]
and “Identifier”: [ “/sign-up/success” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values for the specified identifier in the response JSON that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “SuccessValues”: [ “True”, “Succeeded” ]
status_code
Type: STRUCT
Provider name: StatusCode
Description: Configures inspection of the response status code for success and failure indicators.
failure_codes
Type: UNORDERED_LIST_INT32
Provider name: FailureCodes
Description: Status codes in the response that indicate a failed login or account creation attempt. To be counted as a failure, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “FailureCodes”: [ 400, 404 ]
success_codes
Type: UNORDERED_LIST_INT32
Provider name: SuccessCodes
Description: Status codes in the response that indicate a successful login or account creation attempt. To be counted as a success, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “SuccessCodes”: [ 200, 201 ]
aws_managed_rules_atp_rule_set
Type: STRUCT
Provider name: AWSManagedRulesATPRuleSet
Description: Additional configuration for using the account takeover prevention (ATP) managed rule group, AWSManagedRulesATPRuleSet
. Use this to provide login request information to the rule group. For web ACLs that protect CloudFront distributions, use this to also provide the information about how your distribution responds to login requests. This configuration replaces the individual configuration fields in ManagedRuleGroupConfig
and provides additional feature configuration. For information about using the ATP managed rule group, see WAF Fraud Control account takeover prevention (ATP) rule group and WAF Fraud Control account takeover prevention (ATP) in the WAF Developer Guide.
enable_regex_in_path
Type: BOOLEAN
Provider name: EnableRegexInPath
Description: Allow the use of regular expressions in the login page path.
login_path
Type: STRING
Provider name: LoginPath
Description: The path of the login endpoint for your application. For example, for the URL https://example.com/web/login
, you would provide the path /web/login
. Login paths that start with the path that you provide are considered a match. For example /web/login
matches the login paths /web/login
, /web/login/
, /web/loginPage
, and /web/login/thisPage
, but doesn’t match the login path /home/web/login
or /website/login
. The rule group inspects only HTTP POST
requests to your specified login endpoint.
request_inspection
Type: STRUCT
Provider name: RequestInspection
Description: The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
password_field
Type: STRUCT
Provider name: PasswordField
Description: The name of the field in the request payload that contains your customer’s password. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the password field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
payload_type
Type: STRING
Provider name: PayloadType
Description: The payload type for your login endpoint, either JSON or form encoded.
username_field
Type: STRUCT
Provider name: UsernameField
Description: The name of the field in the request payload that contains your customer’s username. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
identifier
Type: STRING
Provider name: Identifier
Description: The name of the username field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
response_inspection
Type: STRUCT
Provider name: ResponseInspection
Description: The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates. Response inspection is available only in web ACLs that protect Amazon CloudFront distributions. The ATP rule group evaluates the responses that your protected resources send back to client login attempts, keeping count of successful and failed attempts for each IP address and client session. Using this information, the rule group labels and mitigates requests from client sessions and IP addresses that have had too many failed login attempts in a short amount of time.
body_contains
Type: STRUCT
Provider name: BodyContains
Description: Configures inspection of the response body for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response body.
failure_strings
Type: UNORDERED_LIST_STRING
Provider name: FailureStrings
Description: Strings in the body of the response that indicate a failed login or account creation attempt. To be counted as a failure, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON example: “FailureStrings”: [ “Request failed” ]
success_strings
Type: UNORDERED_LIST_STRING
Provider name: SuccessStrings
Description: Strings in the body of the response that indicate a successful login or account creation attempt. To be counted as a success, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON examples: “SuccessStrings”: [ “Login successful” ]
and “SuccessStrings”: [ “Account creation successful”, “Welcome to our site!” ]
header
Type: STRUCT
Provider name: Header
Description: Configures inspection of the response header for success and failure indicators.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values in the response header with the specified name that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “FailureValues”: [ “LoginFailed”, “Failed login” ]
and “FailureValues”: [ “AccountCreationFailed” ]
name
Type: STRING
Provider name: Name
Description: The name of the header to match against. The name must be an exact match, including case. JSON example: “Name”: [ “RequestResult” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values in the response header with the specified name that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “SuccessValues”: [ “LoginPassed”, “Successful login” ]
and “SuccessValues”: [ “AccountCreated”, “Successful account creation” ]
json
Type: STRUCT
Provider name: Json
Description: Configures inspection of the response JSON for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response JSON.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values for the specified identifier in the response JSON that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “FailureValues”: [ “False”, “Failed” ]
identifier
Type: STRING
Provider name: Identifier
Description: The identifier for the value to match against in the JSON. The identifier must be an exact match, including case. JSON examples: “Identifier”: [ “/login/success” ]
and “Identifier”: [ “/sign-up/success” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values for the specified identifier in the response JSON that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “SuccessValues”: [ “True”, “Succeeded” ]
status_code
Type: STRUCT
Provider name: StatusCode
Description: Configures inspection of the response status code for success and failure indicators.
failure_codes
Type: UNORDERED_LIST_INT32
Provider name: FailureCodes
Description: Status codes in the response that indicate a failed login or account creation attempt. To be counted as a failure, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “FailureCodes”: [ 400, 404 ]
success_codes
Type: UNORDERED_LIST_INT32
Provider name: SuccessCodes
Description: Status codes in the response that indicate a successful login or account creation attempt. To be counted as a success, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “SuccessCodes”: [ 200, 201 ]
aws_managed_rules_bot_control_rule_set
Type: STRUCT
Provider name: AWSManagedRulesBotControlRuleSet
Description: Additional configuration for using the Bot Control managed rule group. Use this to specify the inspection level that you want to use. For information about using the Bot Control managed rule group, see WAF Bot Control rule group and WAF Bot Control in the WAF Developer Guide.
enable_machine_learning
Type: BOOLEAN
Provider name: EnableMachineLearning
Description: Applies only to the targeted inspection level. Determines whether to use machine learning (ML) to analyze your web traffic for bot-related activity. Machine learning is required for the Bot Control rules TGT_ML_CoordinatedActivityLow
and TGT_ML_CoordinatedActivityMedium
, which inspect for anomalous behavior that might indicate distributed, coordinated bot activity. For more information about this choice, see the listing for these rules in the table at Bot Control rules listing in the WAF Developer Guide.
Default: TRUE
inspection_level
Type: STRING
Provider name: InspectionLevel
Description: The inspection level to use for the Bot Control rule group. The common level is the least expensive. The targeted level includes all common level rules and adds rules with more advanced inspection criteria. For details, see WAF Bot Control rule group in the WAF Developer Guide.
login_path
Type: STRING
Provider name: LoginPath
Description: Instead of this setting, provide your configuration under AWSManagedRulesATPRuleSet
.
password_field
Type: STRUCT
Provider name: PasswordField
Description: Instead of this setting, provide your configuration under the request inspection configuration for AWSManagedRulesATPRuleSet
or AWSManagedRulesACFPRuleSet
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the password field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
payload_type
Type: STRING
Provider name: PayloadType
Description: Instead of this setting, provide your configuration under the request inspection configuration for AWSManagedRulesATPRuleSet
or AWSManagedRulesACFPRuleSet
.
username_field
Type: STRUCT
Provider name: UsernameField
Description: Instead of this setting, provide your configuration under the request inspection configuration for AWSManagedRulesATPRuleSet
or AWSManagedRulesACFPRuleSet
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the username field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
name
Type: STRING
Provider name: Name
Description: The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
rule_action_overrides
Type: UNORDERED_LIST_STRUCT
Provider name: RuleActionOverrides
Description: Action settings to use in the place of the rule actions that are configured inside the rule group. You specify one override for each rule whose action you want to change. You can use overrides for testing, for example you can override all of rule actions to Count
and then monitor the resulting count metrics to understand how the rule group would handle your web traffic. You can also permanently override some or all actions, to modify how the rule group manages your web traffic.
action_to_use
Type: STRUCT
Provider name: ActionToUse
Description: The override action to use, in place of the configured action of the rule in the rule group.
allow
Type: STRUCT
Provider name: Allow
Description: Instructs WAF to allow the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
block
Type: STRUCT
Provider name: Block
Description: Instructs WAF to block the web request.
custom_response
Type: STRUCT
Provider name: CustomResponse
Description: Defines a custom response for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
custom_response_body_key
Type: STRING
Provider name: CustomResponseBodyKey
Description: References the response body that you want WAF to return to the web request client. You can define a custom response for a rule action or a default web ACL action that is set to block. To do this, you first define the response body key and value in the CustomResponseBodies
setting for the WebACL or RuleGroup where you want to use it. Then, in the rule action or web ACL default action BlockAction
setting, you reference the response body using this key.
response_code
Type: INT32
Provider name: ResponseCode
Description: The HTTP status code to return to the client. For a list of status codes that you can use in your custom responses, see Supported status codes for custom response in the WAF Developer Guide.
response_headers
Type: UNORDERED_LIST_STRUCT
Provider name: ResponseHeaders
Description: The HTTP headers to use in the response. You can specify any header name except for content-type
. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
captcha
Type: STRUCT
Provider name: Captcha
Description: Instructs WAF to run a CAPTCHA
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the CAPTCHA
inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
challenge
Type: STRUCT
Provider name: Challenge
Description: Instructs WAF to run a Challenge
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the challenge inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
count
Type: STRUCT
Provider name: Count
Description: Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
name
Type: STRING
Provider name: Name
Description: The name of the rule to override.
vendor_name
Type: STRING
Provider name: VendorName
Description: The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
version
Type: STRING
Provider name: Version
Description: The version of the managed rule group to use. If you specify this, the version setting is fixed until you change it. If you don’t specify this, WAF uses the vendor’s default version, and then keeps the version at the vendor’s default when the vendor updates the managed rule group settings.
rule_group_reference_statement
Type: STRUCT
Provider name: RuleGroupReferenceStatement
Description: A statement used by Firewall Manager to run the rules that are defined in a rule group. This is managed by Firewall Manager for an Firewall Manager WAF policy.
arn
Type: STRING
Provider name: ARN
Description: The Amazon Resource Name (ARN) of the entity.
excluded_rules
Type: UNORDERED_LIST_STRUCT
Provider name: ExcludedRules
Description: Rules in the referenced rule group whose actions are set to Count
. Instead of this option, use RuleActionOverrides
. It accepts any valid action setting, including Count
.
name
Type: STRING
Provider name: Name
Description: The name of the rule whose action you want to override to Count
.
rule_action_overrides
Type: UNORDERED_LIST_STRUCT
Provider name: RuleActionOverrides
Description: Action settings to use in the place of the rule actions that are configured inside the rule group. You specify one override for each rule whose action you want to change. You can use overrides for testing, for example you can override all of rule actions to Count
and then monitor the resulting count metrics to understand how the rule group would handle your web traffic. You can also permanently override some or all actions, to modify how the rule group manages your web traffic.
action_to_use
Type: STRUCT
Provider name: ActionToUse
Description: The override action to use, in place of the configured action of the rule in the rule group.
allow
Type: STRUCT
Provider name: Allow
Description: Instructs WAF to allow the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
block
Type: STRUCT
Provider name: Block
Description: Instructs WAF to block the web request.
custom_response
Type: STRUCT
Provider name: CustomResponse
Description: Defines a custom response for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
custom_response_body_key
Type: STRING
Provider name: CustomResponseBodyKey
Description: References the response body that you want WAF to return to the web request client. You can define a custom response for a rule action or a default web ACL action that is set to block. To do this, you first define the response body key and value in the CustomResponseBodies
setting for the WebACL or RuleGroup where you want to use it. Then, in the rule action or web ACL default action BlockAction
setting, you reference the response body using this key.
response_code
Type: INT32
Provider name: ResponseCode
Description: The HTTP status code to return to the client. For a list of status codes that you can use in your custom responses, see Supported status codes for custom response in the WAF Developer Guide.
response_headers
Type: UNORDERED_LIST_STRUCT
Provider name: ResponseHeaders
Description: The HTTP headers to use in the response. You can specify any header name except for content-type
. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
captcha
Type: STRUCT
Provider name: Captcha
Description: Instructs WAF to run a CAPTCHA
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the CAPTCHA
inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
challenge
Type: STRUCT
Provider name: Challenge
Description: Instructs WAF to run a Challenge
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the challenge inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
count
Type: STRUCT
Provider name: Count
Description: Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
name
Type: STRING
Provider name: Name
Description: The name of the rule to override.
name
Type: STRING
Provider name: Name
Description: The name of the rule group. You cannot change the name of a rule group after you create it.
override_action
Type: STRUCT
Provider name: OverrideAction
Description: The action to use in the place of the action that results from the rule group evaluation. Set the override action to none to leave the result of the rule group alone. Set it to count to override the result to count only. You can only use this for rule statements that reference a rule group, like RuleGroupReferenceStatement
and ManagedRuleGroupStatement
. This option is usually set to none. It does not affect how the rules in the rule group are evaluated. If you want the rules in the rule group to only count matches, do not use this and instead use the rule action override option, with Count
action, in your rule group reference statement settings.
count
Type: STRUCT
Provider name: Count
Description: Override the rule group evaluation result to count only. This option is usually set to none. It does not affect how the rules in the rule group are evaluated. If you want the rules in the rule group to only count matches, do not use this and instead use the rule action override option, with Count
action, in your rule group reference statement settings.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
none
Type: STRUCT
Provider name: None
Description: Don’t override the rule group evaluation result. This is the most common setting.
priority
Type: INT32
Provider name: Priority
Description: If you define more than one rule group in the first or last Firewall Manager rule groups, WAF evaluates each request against the rule groups in order, starting from the lowest priority setting. The priorities don’t need to be consecutive, but they must all be different.
visibility_config
Type: STRUCT
Provider name: VisibilityConfig
Description: Defines and enables Amazon CloudWatch metrics and web request sample collection.
cloud_watch_metrics_enabled
Type: BOOLEAN
Provider name: CloudWatchMetricsEnabled
Description: Indicates whether the associated resource sends metrics to Amazon CloudWatch. For the list of available metrics, see WAF Metrics in the WAF Developer Guide. For web ACLs, the metrics are for web requests that have the web ACL default action applied. WAF applies the default action to web requests that pass the inspection of all rules in the web ACL without being either allowed or blocked. For more information, see The web ACL default action in the WAF Developer Guide.
metric_name
Type: STRING
Provider name: MetricName
Description: A name of the Amazon CloudWatch metric dimension. The name can contain only the characters: A-Z, a-z, 0-9, - (hyphen), and _ (underscore). The name can be from one to 128 characters long. It can’t contain whitespace or metric names that are reserved for WAF, for example All
and Default_Action
.
sampled_requests_enabled
Type: BOOLEAN
Provider name: SampledRequestsEnabled
Description: Indicates whether WAF should store a sampling of the web requests that match the rules. You can view the sampled requests through the WAF console. Request sampling doesn’t provide a field redaction option, and any field redaction that you specify in your logging configuration doesn’t affect sampling. The only way to exclude fields from request sampling is by disabling sampling in the web ACL visibility configuration.
pre_process_firewall_manager_rule_groups
Type: UNORDERED_LIST_STRUCT
Provider name: PreProcessFirewallManagerRuleGroups
Description: The first set of rules for WAF to process in the web ACL. This is defined in an Firewall Manager WAF policy and contains only rule group references. You can’t alter these. Any rules and rule groups that you define for the web ACL are prioritized after these. In the Firewall Manager WAF policy, the Firewall Manager administrator can define a set of rule groups to run first in the web ACL and a set of rule groups to run last. Within each set, the administrator prioritizes the rule groups, to determine their relative processing order.
firewall_manager_statement
Type: STRUCT
Provider name: FirewallManagerStatement
Description: The processing guidance for an Firewall Manager rule. This is like a regular rule Statement, but it can only contain a rule group reference.
managed_rule_group_statement
Type: STRUCT
Provider name: ManagedRuleGroupStatement
Description: A statement used by Firewall Manager to run the rules that are defined in a managed rule group. This is managed by Firewall Manager for an Firewall Manager WAF policy.
excluded_rules
Type: UNORDERED_LIST_STRUCT
Provider name: ExcludedRules
Description: Rules in the referenced rule group whose actions are set to Count
. Instead of this option, use RuleActionOverrides
. It accepts any valid action setting, including Count
.
name
Type: STRING
Provider name: Name
Description: The name of the rule whose action you want to override to Count
.
managed_rule_group_configs
Type: UNORDERED_LIST_STRUCT
Provider name: ManagedRuleGroupConfigs
Description: Additional information that’s used by a managed rule group. Many managed rule groups don’t require this. The rule groups used for intelligent threat mitigation require additional configuration:- Use the
AWSManagedRulesACFPRuleSet
configuration object to configure the account creation fraud prevention managed rule group. The configuration includes the registration and sign-up pages of your application and the locations in the account creation request payload of data, such as the user email and phone number fields. - Use the
AWSManagedRulesATPRuleSet
configuration object to configure the account takeover prevention managed rule group. The configuration includes the sign-in page of your application and the locations in the login request payload of data such as the username and password. - Use the
AWSManagedRulesBotControlRuleSet
configuration object to configure the protection level that you want the Bot Control rule group to use.
aws_managed_rules_acfp_rule_set
Type: STRUCT
Provider name: AWSManagedRulesACFPRuleSet
Description: Additional configuration for using the account creation fraud prevention (ACFP) managed rule group, AWSManagedRulesACFPRuleSet
. Use this to provide account creation request information to the rule group. For web ACLs that protect CloudFront distributions, use this to also provide the information about how your distribution responds to account creation requests. For information about using the ACFP managed rule group, see WAF Fraud Control account creation fraud prevention (ACFP) rule group and WAF Fraud Control account creation fraud prevention (ACFP) in the WAF Developer Guide.
creation_path
Type: STRING
Provider name: CreationPath
Description: The path of the account creation endpoint for your application. This is the page on your website that accepts the completed registration form for a new user. This page must accept POST
requests. For example, for the URL https://example.com/web/newaccount
, you would provide the path /web/newaccount
. Account creation page paths that start with the path that you provide are considered a match. For example /web/newaccount
matches the account creation paths /web/newaccount
, /web/newaccount/
, /web/newaccountPage
, and /web/newaccount/thisPage
, but doesn’t match the path /home/web/newaccount
or /website/newaccount
.
enable_regex_in_path
Type: BOOLEAN
Provider name: EnableRegexInPath
Description: Allow the use of regular expressions in the registration page path and the account creation path.
registration_page_path
Type: STRING
Provider name: RegistrationPagePath
Description: The path of the account registration endpoint for your application. This is the page on your website that presents the registration form to new users. This page must accept GET
text/html requests. For example, for the URL https://example.com/web/registration
, you would provide the path /web/registration
. Registration page paths that start with the path that you provide are considered a match. For example /web/registration
matches the registration paths /web/registration
, /web/registration/
, /web/registrationPage
, and /web/registration/thisPage
, but doesn’t match the path /home/web/registration
or /website/registration
.
request_inspection
Type: STRUCT
Provider name: RequestInspection
Description: The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
address_fields
Type: UNORDERED_LIST_STRUCT
Provider name: AddressFields
Description: The names of the fields in the request payload that contain your customer’s primary physical address. Order the address fields in the array exactly as they are ordered in the request payload. How you specify the address fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryaddressline1”: “THE_ADDRESS1”, “primaryaddressline2”: “THE_ADDRESS2”, “primaryaddressline3”: “THE_ADDRESS3” } }
, the address field idenfiers are /form/primaryaddressline1
, /form/primaryaddressline2
, and /form/primaryaddressline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
, the address fields identifiers are primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of a single primary address field. How you specify the address fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryaddressline1”: “THE_ADDRESS1”, “primaryaddressline2”: “THE_ADDRESS2”, “primaryaddressline3”: “THE_ADDRESS3” } }
, the address field idenfiers are /form/primaryaddressline1
, /form/primaryaddressline2
, and /form/primaryaddressline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
, the address fields identifiers are primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
.
email_field
Type: STRUCT
Provider name: EmailField
Description: The name of the field in the request payload that contains your customer’s email. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “email”: “THE_EMAIL” } }
, the email field specification is /form/email
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
email1
, the email field specification is email1
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the email field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “email”: “THE_EMAIL” } }
, the email field specification is /form/email
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
email1
, the email field specification is email1
.
password_field
Type: STRUCT
Provider name: PasswordField
Description: The name of the field in the request payload that contains your customer’s password. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the password field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
payload_type
Type: STRING
Provider name: PayloadType
Description: The payload type for your account creation endpoint, either JSON or form encoded.
phone_number_fields
Type: UNORDERED_LIST_STRUCT
Provider name: PhoneNumberFields
Description: The names of the fields in the request payload that contain your customer’s primary phone number. Order the phone number fields in the array exactly as they are ordered in the request payload. How you specify the phone number fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryphoneline1”: “THE_PHONE1”, “primaryphoneline2”: “THE_PHONE2”, “primaryphoneline3”: “THE_PHONE3” } }
, the phone number field identifiers are /form/primaryphoneline1
, /form/primaryphoneline2
, and /form/primaryphoneline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
, the phone number field identifiers are primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of a single primary phone number field. How you specify the phone number fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryphoneline1”: “THE_PHONE1”, “primaryphoneline2”: “THE_PHONE2”, “primaryphoneline3”: “THE_PHONE3” } }
, the phone number field identifiers are /form/primaryphoneline1
, /form/primaryphoneline2
, and /form/primaryphoneline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
, the phone number field identifiers are primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
.
username_field
Type: STRUCT
Provider name: UsernameField
Description: The name of the field in the request payload that contains your customer’s username. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
identifier
Type: STRING
Provider name: Identifier
Description: The name of the username field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
response_inspection
Type: STRUCT
Provider name: ResponseInspection
Description: The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates. Response inspection is available only in web ACLs that protect Amazon CloudFront distributions. The ACFP rule group evaluates the responses that your protected resources send back to client account creation attempts, keeping count of successful and failed attempts from each IP address and client session. Using this information, the rule group labels and mitigates requests from client sessions and IP addresses that have had too many successful account creation attempts in a short amount of time.
body_contains
Type: STRUCT
Provider name: BodyContains
Description: Configures inspection of the response body for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response body.
failure_strings
Type: UNORDERED_LIST_STRING
Provider name: FailureStrings
Description: Strings in the body of the response that indicate a failed login or account creation attempt. To be counted as a failure, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON example: “FailureStrings”: [ “Request failed” ]
success_strings
Type: UNORDERED_LIST_STRING
Provider name: SuccessStrings
Description: Strings in the body of the response that indicate a successful login or account creation attempt. To be counted as a success, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON examples: “SuccessStrings”: [ “Login successful” ]
and “SuccessStrings”: [ “Account creation successful”, “Welcome to our site!” ]
header
Type: STRUCT
Provider name: Header
Description: Configures inspection of the response header for success and failure indicators.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values in the response header with the specified name that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “FailureValues”: [ “LoginFailed”, “Failed login” ]
and “FailureValues”: [ “AccountCreationFailed” ]
name
Type: STRING
Provider name: Name
Description: The name of the header to match against. The name must be an exact match, including case. JSON example: “Name”: [ “RequestResult” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values in the response header with the specified name that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “SuccessValues”: [ “LoginPassed”, “Successful login” ]
and “SuccessValues”: [ “AccountCreated”, “Successful account creation” ]
json
Type: STRUCT
Provider name: Json
Description: Configures inspection of the response JSON for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response JSON.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values for the specified identifier in the response JSON that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “FailureValues”: [ “False”, “Failed” ]
identifier
Type: STRING
Provider name: Identifier
Description: The identifier for the value to match against in the JSON. The identifier must be an exact match, including case. JSON examples: “Identifier”: [ “/login/success” ]
and “Identifier”: [ “/sign-up/success” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values for the specified identifier in the response JSON that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “SuccessValues”: [ “True”, “Succeeded” ]
status_code
Type: STRUCT
Provider name: StatusCode
Description: Configures inspection of the response status code for success and failure indicators.
failure_codes
Type: UNORDERED_LIST_INT32
Provider name: FailureCodes
Description: Status codes in the response that indicate a failed login or account creation attempt. To be counted as a failure, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “FailureCodes”: [ 400, 404 ]
success_codes
Type: UNORDERED_LIST_INT32
Provider name: SuccessCodes
Description: Status codes in the response that indicate a successful login or account creation attempt. To be counted as a success, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “SuccessCodes”: [ 200, 201 ]
aws_managed_rules_atp_rule_set
Type: STRUCT
Provider name: AWSManagedRulesATPRuleSet
Description: Additional configuration for using the account takeover prevention (ATP) managed rule group, AWSManagedRulesATPRuleSet
. Use this to provide login request information to the rule group. For web ACLs that protect CloudFront distributions, use this to also provide the information about how your distribution responds to login requests. This configuration replaces the individual configuration fields in ManagedRuleGroupConfig
and provides additional feature configuration. For information about using the ATP managed rule group, see WAF Fraud Control account takeover prevention (ATP) rule group and WAF Fraud Control account takeover prevention (ATP) in the WAF Developer Guide.
enable_regex_in_path
Type: BOOLEAN
Provider name: EnableRegexInPath
Description: Allow the use of regular expressions in the login page path.
login_path
Type: STRING
Provider name: LoginPath
Description: The path of the login endpoint for your application. For example, for the URL https://example.com/web/login
, you would provide the path /web/login
. Login paths that start with the path that you provide are considered a match. For example /web/login
matches the login paths /web/login
, /web/login/
, /web/loginPage
, and /web/login/thisPage
, but doesn’t match the login path /home/web/login
or /website/login
. The rule group inspects only HTTP POST
requests to your specified login endpoint.
request_inspection
Type: STRUCT
Provider name: RequestInspection
Description: The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
password_field
Type: STRUCT
Provider name: PasswordField
Description: The name of the field in the request payload that contains your customer’s password. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the password field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
payload_type
Type: STRING
Provider name: PayloadType
Description: The payload type for your login endpoint, either JSON or form encoded.
username_field
Type: STRUCT
Provider name: UsernameField
Description: The name of the field in the request payload that contains your customer’s username. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
identifier
Type: STRING
Provider name: Identifier
Description: The name of the username field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
response_inspection
Type: STRUCT
Provider name: ResponseInspection
Description: The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates. Response inspection is available only in web ACLs that protect Amazon CloudFront distributions. The ATP rule group evaluates the responses that your protected resources send back to client login attempts, keeping count of successful and failed attempts for each IP address and client session. Using this information, the rule group labels and mitigates requests from client sessions and IP addresses that have had too many failed login attempts in a short amount of time.
body_contains
Type: STRUCT
Provider name: BodyContains
Description: Configures inspection of the response body for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response body.
failure_strings
Type: UNORDERED_LIST_STRING
Provider name: FailureStrings
Description: Strings in the body of the response that indicate a failed login or account creation attempt. To be counted as a failure, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON example: “FailureStrings”: [ “Request failed” ]
success_strings
Type: UNORDERED_LIST_STRING
Provider name: SuccessStrings
Description: Strings in the body of the response that indicate a successful login or account creation attempt. To be counted as a success, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON examples: “SuccessStrings”: [ “Login successful” ]
and “SuccessStrings”: [ “Account creation successful”, “Welcome to our site!” ]
header
Type: STRUCT
Provider name: Header
Description: Configures inspection of the response header for success and failure indicators.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values in the response header with the specified name that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “FailureValues”: [ “LoginFailed”, “Failed login” ]
and “FailureValues”: [ “AccountCreationFailed” ]
name
Type: STRING
Provider name: Name
Description: The name of the header to match against. The name must be an exact match, including case. JSON example: “Name”: [ “RequestResult” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values in the response header with the specified name that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “SuccessValues”: [ “LoginPassed”, “Successful login” ]
and “SuccessValues”: [ “AccountCreated”, “Successful account creation” ]
json
Type: STRUCT
Provider name: Json
Description: Configures inspection of the response JSON for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response JSON.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values for the specified identifier in the response JSON that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “FailureValues”: [ “False”, “Failed” ]
identifier
Type: STRING
Provider name: Identifier
Description: The identifier for the value to match against in the JSON. The identifier must be an exact match, including case. JSON examples: “Identifier”: [ “/login/success” ]
and “Identifier”: [ “/sign-up/success” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values for the specified identifier in the response JSON that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “SuccessValues”: [ “True”, “Succeeded” ]
status_code
Type: STRUCT
Provider name: StatusCode
Description: Configures inspection of the response status code for success and failure indicators.
failure_codes
Type: UNORDERED_LIST_INT32
Provider name: FailureCodes
Description: Status codes in the response that indicate a failed login or account creation attempt. To be counted as a failure, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “FailureCodes”: [ 400, 404 ]
success_codes
Type: UNORDERED_LIST_INT32
Provider name: SuccessCodes
Description: Status codes in the response that indicate a successful login or account creation attempt. To be counted as a success, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “SuccessCodes”: [ 200, 201 ]
aws_managed_rules_bot_control_rule_set
Type: STRUCT
Provider name: AWSManagedRulesBotControlRuleSet
Description: Additional configuration for using the Bot Control managed rule group. Use this to specify the inspection level that you want to use. For information about using the Bot Control managed rule group, see WAF Bot Control rule group and WAF Bot Control in the WAF Developer Guide.
enable_machine_learning
Type: BOOLEAN
Provider name: EnableMachineLearning
Description: Applies only to the targeted inspection level. Determines whether to use machine learning (ML) to analyze your web traffic for bot-related activity. Machine learning is required for the Bot Control rules TGT_ML_CoordinatedActivityLow
and TGT_ML_CoordinatedActivityMedium
, which inspect for anomalous behavior that might indicate distributed, coordinated bot activity. For more information about this choice, see the listing for these rules in the table at Bot Control rules listing in the WAF Developer Guide.
Default: TRUE
inspection_level
Type: STRING
Provider name: InspectionLevel
Description: The inspection level to use for the Bot Control rule group. The common level is the least expensive. The targeted level includes all common level rules and adds rules with more advanced inspection criteria. For details, see WAF Bot Control rule group in the WAF Developer Guide.
login_path
Type: STRING
Provider name: LoginPath
Description: Instead of this setting, provide your configuration under AWSManagedRulesATPRuleSet
.
password_field
Type: STRUCT
Provider name: PasswordField
Description: Instead of this setting, provide your configuration under the request inspection configuration for AWSManagedRulesATPRuleSet
or AWSManagedRulesACFPRuleSet
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the password field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
payload_type
Type: STRING
Provider name: PayloadType
Description: Instead of this setting, provide your configuration under the request inspection configuration for AWSManagedRulesATPRuleSet
or AWSManagedRulesACFPRuleSet
.
username_field
Type: STRUCT
Provider name: UsernameField
Description: Instead of this setting, provide your configuration under the request inspection configuration for AWSManagedRulesATPRuleSet
or AWSManagedRulesACFPRuleSet
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the username field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
name
Type: STRING
Provider name: Name
Description: The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
rule_action_overrides
Type: UNORDERED_LIST_STRUCT
Provider name: RuleActionOverrides
Description: Action settings to use in the place of the rule actions that are configured inside the rule group. You specify one override for each rule whose action you want to change. You can use overrides for testing, for example you can override all of rule actions to Count
and then monitor the resulting count metrics to understand how the rule group would handle your web traffic. You can also permanently override some or all actions, to modify how the rule group manages your web traffic.
action_to_use
Type: STRUCT
Provider name: ActionToUse
Description: The override action to use, in place of the configured action of the rule in the rule group.
allow
Type: STRUCT
Provider name: Allow
Description: Instructs WAF to allow the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
block
Type: STRUCT
Provider name: Block
Description: Instructs WAF to block the web request.
custom_response
Type: STRUCT
Provider name: CustomResponse
Description: Defines a custom response for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
custom_response_body_key
Type: STRING
Provider name: CustomResponseBodyKey
Description: References the response body that you want WAF to return to the web request client. You can define a custom response for a rule action or a default web ACL action that is set to block. To do this, you first define the response body key and value in the CustomResponseBodies
setting for the WebACL or RuleGroup where you want to use it. Then, in the rule action or web ACL default action BlockAction
setting, you reference the response body using this key.
response_code
Type: INT32
Provider name: ResponseCode
Description: The HTTP status code to return to the client. For a list of status codes that you can use in your custom responses, see Supported status codes for custom response in the WAF Developer Guide.
response_headers
Type: UNORDERED_LIST_STRUCT
Provider name: ResponseHeaders
Description: The HTTP headers to use in the response. You can specify any header name except for content-type
. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
captcha
Type: STRUCT
Provider name: Captcha
Description: Instructs WAF to run a CAPTCHA
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the CAPTCHA
inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
challenge
Type: STRUCT
Provider name: Challenge
Description: Instructs WAF to run a Challenge
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the challenge inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
count
Type: STRUCT
Provider name: Count
Description: Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
name
Type: STRING
Provider name: Name
Description: The name of the rule to override.
vendor_name
Type: STRING
Provider name: VendorName
Description: The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
version
Type: STRING
Provider name: Version
Description: The version of the managed rule group to use. If you specify this, the version setting is fixed until you change it. If you don’t specify this, WAF uses the vendor’s default version, and then keeps the version at the vendor’s default when the vendor updates the managed rule group settings.
rule_group_reference_statement
Type: STRUCT
Provider name: RuleGroupReferenceStatement
Description: A statement used by Firewall Manager to run the rules that are defined in a rule group. This is managed by Firewall Manager for an Firewall Manager WAF policy.
arn
Type: STRING
Provider name: ARN
Description: The Amazon Resource Name (ARN) of the entity.
excluded_rules
Type: UNORDERED_LIST_STRUCT
Provider name: ExcludedRules
Description: Rules in the referenced rule group whose actions are set to Count
. Instead of this option, use RuleActionOverrides
. It accepts any valid action setting, including Count
.
name
Type: STRING
Provider name: Name
Description: The name of the rule whose action you want to override to Count
.
rule_action_overrides
Type: UNORDERED_LIST_STRUCT
Provider name: RuleActionOverrides
Description: Action settings to use in the place of the rule actions that are configured inside the rule group. You specify one override for each rule whose action you want to change. You can use overrides for testing, for example you can override all of rule actions to Count
and then monitor the resulting count metrics to understand how the rule group would handle your web traffic. You can also permanently override some or all actions, to modify how the rule group manages your web traffic.
action_to_use
Type: STRUCT
Provider name: ActionToUse
Description: The override action to use, in place of the configured action of the rule in the rule group.
allow
Type: STRUCT
Provider name: Allow
Description: Instructs WAF to allow the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
block
Type: STRUCT
Provider name: Block
Description: Instructs WAF to block the web request.
custom_response
Type: STRUCT
Provider name: CustomResponse
Description: Defines a custom response for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
custom_response_body_key
Type: STRING
Provider name: CustomResponseBodyKey
Description: References the response body that you want WAF to return to the web request client. You can define a custom response for a rule action or a default web ACL action that is set to block. To do this, you first define the response body key and value in the CustomResponseBodies
setting for the WebACL or RuleGroup where you want to use it. Then, in the rule action or web ACL default action BlockAction
setting, you reference the response body using this key.
response_code
Type: INT32
Provider name: ResponseCode
Description: The HTTP status code to return to the client. For a list of status codes that you can use in your custom responses, see Supported status codes for custom response in the WAF Developer Guide.
response_headers
Type: UNORDERED_LIST_STRUCT
Provider name: ResponseHeaders
Description: The HTTP headers to use in the response. You can specify any header name except for content-type
. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
captcha
Type: STRUCT
Provider name: Captcha
Description: Instructs WAF to run a CAPTCHA
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the CAPTCHA
inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
challenge
Type: STRUCT
Provider name: Challenge
Description: Instructs WAF to run a Challenge
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the challenge inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
count
Type: STRUCT
Provider name: Count
Description: Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
name
Type: STRING
Provider name: Name
Description: The name of the rule to override.
name
Type: STRING
Provider name: Name
Description: The name of the rule group. You cannot change the name of a rule group after you create it.
override_action
Type: STRUCT
Provider name: OverrideAction
Description: The action to use in the place of the action that results from the rule group evaluation. Set the override action to none to leave the result of the rule group alone. Set it to count to override the result to count only. You can only use this for rule statements that reference a rule group, like RuleGroupReferenceStatement
and ManagedRuleGroupStatement
. This option is usually set to none. It does not affect how the rules in the rule group are evaluated. If you want the rules in the rule group to only count matches, do not use this and instead use the rule action override option, with Count
action, in your rule group reference statement settings.
count
Type: STRUCT
Provider name: Count
Description: Override the rule group evaluation result to count only. This option is usually set to none. It does not affect how the rules in the rule group are evaluated. If you want the rules in the rule group to only count matches, do not use this and instead use the rule action override option, with Count
action, in your rule group reference statement settings.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
none
Type: STRUCT
Provider name: None
Description: Don’t override the rule group evaluation result. This is the most common setting.
priority
Type: INT32
Provider name: Priority
Description: If you define more than one rule group in the first or last Firewall Manager rule groups, WAF evaluates each request against the rule groups in order, starting from the lowest priority setting. The priorities don’t need to be consecutive, but they must all be different.
visibility_config
Type: STRUCT
Provider name: VisibilityConfig
Description: Defines and enables Amazon CloudWatch metrics and web request sample collection.
cloud_watch_metrics_enabled
Type: BOOLEAN
Provider name: CloudWatchMetricsEnabled
Description: Indicates whether the associated resource sends metrics to Amazon CloudWatch. For the list of available metrics, see WAF Metrics in the WAF Developer Guide. For web ACLs, the metrics are for web requests that have the web ACL default action applied. WAF applies the default action to web requests that pass the inspection of all rules in the web ACL without being either allowed or blocked. For more information, see The web ACL default action in the WAF Developer Guide.
metric_name
Type: STRING
Provider name: MetricName
Description: A name of the Amazon CloudWatch metric dimension. The name can contain only the characters: A-Z, a-z, 0-9, - (hyphen), and _ (underscore). The name can be from one to 128 characters long. It can’t contain whitespace or metric names that are reserved for WAF, for example All
and Default_Action
.
sampled_requests_enabled
Type: BOOLEAN
Provider name: SampledRequestsEnabled
Description: Indicates whether WAF should store a sampling of the web requests that match the rules. You can view the sampled requests through the WAF console. Request sampling doesn’t provide a field redaction option, and any field redaction that you specify in your logging configuration doesn’t affect sampling. The only way to exclude fields from request sampling is by disabling sampling in the web ACL visibility configuration.
rules
Type: UNORDERED_LIST_STRUCT
Provider name: Rules
Description: The Rule statements used to identify the web requests that you want to manage. Each rule includes one top-level statement that WAF uses to identify matching web requests, and parameters that govern how WAF handles them.
action
Type: STRUCT
Provider name: Action
Description: The action that WAF should take on a web request when it matches the rule statement. Settings at the web ACL level can override the rule action setting. This is used only for rules whose statements do not reference a rule group. Rule statements that reference a rule group include RuleGroupReferenceStatement
and ManagedRuleGroupStatement
. You must specify either this Action
setting or the rule OverrideAction
setting, but not both:- If the rule statement does not reference a rule group, use this rule action setting and not the rule override action setting.
- If the rule statement references a rule group, use the override action setting and not this action setting.
allow
Type: STRUCT
Provider name: Allow
Description: Instructs WAF to allow the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
block
Type: STRUCT
Provider name: Block
Description: Instructs WAF to block the web request.
custom_response
Type: STRUCT
Provider name: CustomResponse
Description: Defines a custom response for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
custom_response_body_key
Type: STRING
Provider name: CustomResponseBodyKey
Description: References the response body that you want WAF to return to the web request client. You can define a custom response for a rule action or a default web ACL action that is set to block. To do this, you first define the response body key and value in the CustomResponseBodies
setting for the WebACL or RuleGroup where you want to use it. Then, in the rule action or web ACL default action BlockAction
setting, you reference the response body using this key.
response_code
Type: INT32
Provider name: ResponseCode
Description: The HTTP status code to return to the client. For a list of status codes that you can use in your custom responses, see Supported status codes for custom response in the WAF Developer Guide.
response_headers
Type: UNORDERED_LIST_STRUCT
Provider name: ResponseHeaders
Description: The HTTP headers to use in the response. You can specify any header name except for content-type
. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
captcha
Type: STRUCT
Provider name: Captcha
Description: Instructs WAF to run a CAPTCHA
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the CAPTCHA
inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
challenge
Type: STRUCT
Provider name: Challenge
Description: Instructs WAF to run a Challenge
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the challenge inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
count
Type: STRUCT
Provider name: Count
Description: Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
captcha_config
Type: STRUCT
Provider name: CaptchaConfig
Description: Specifies how WAF should handle CAPTCHA
evaluations. If you don’t specify this, WAF uses the CAPTCHA
configuration that’s defined for the web ACL.
immunity_time_property
Type: STRUCT
Provider name: ImmunityTimeProperty
Description: Determines how long a CAPTCHA
timestamp in the token remains valid after the client successfully solves a CAPTCHA
puzzle.
immunity_time
Type: INT64
Provider name: ImmunityTime
Description: The amount of time, in seconds, that a CAPTCHA
or challenge timestamp is considered valid by WAF. The default setting is 300. For the Challenge action, the minimum setting is 300.
challenge_config
Type: STRUCT
Provider name: ChallengeConfig
Description: Specifies how WAF should handle Challenge
evaluations. If you don’t specify this, WAF uses the challenge configuration that’s defined for the web ACL.
immunity_time_property
Type: STRUCT
Provider name: ImmunityTimeProperty
Description: Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
immunity_time
Type: INT64
Provider name: ImmunityTime
Description: The amount of time, in seconds, that a CAPTCHA
or challenge timestamp is considered valid by WAF. The default setting is 300. For the Challenge action, the minimum setting is 300.
name
Type: STRING
Provider name: Name
Description: The name of the rule. If you change the name of a Rule
after you create it and you want the rule’s metric name to reflect the change, update the metric name in the rule’s VisibilityConfig
settings. WAF doesn’t automatically update the metric name when you update the rule name.
override_action
Type: STRUCT
Provider name: OverrideAction
Description: The action to use in the place of the action that results from the rule group evaluation. Set the override action to none to leave the result of the rule group alone. Set it to count to override the result to count only. You can only use this for rule statements that reference a rule group, like RuleGroupReferenceStatement
and ManagedRuleGroupStatement
. This option is usually set to none. It does not affect how the rules in the rule group are evaluated. If you want the rules in the rule group to only count matches, do not use this and instead use the rule action override option, with Count
action, in your rule group reference statement settings.
count
Type: STRUCT
Provider name: Count
Description: Override the rule group evaluation result to count only. This option is usually set to none. It does not affect how the rules in the rule group are evaluated. If you want the rules in the rule group to only count matches, do not use this and instead use the rule action override option, with Count
action, in your rule group reference statement settings.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
none
Type: STRUCT
Provider name: None
Description: Don’t override the rule group evaluation result. This is the most common setting.
priority
Type: INT32
Provider name: Priority
Description: If you define more than one Rule
in a WebACL
, WAF evaluates each request against the Rules
in order based on the value of Priority
. WAF processes rules with lower priority first. The priorities don’t need to be consecutive, but they must all be different.
rule_labels
Type: UNORDERED_LIST_STRUCT
Provider name: RuleLabels
Description: Labels to apply to web requests that match the rule match statement. WAF applies fully qualified labels to matching web requests. A fully qualified label is the concatenation of a label namespace and a rule label. The rule’s rule group or web ACL defines the label namespace. Rules that run after this rule in the web ACL can match against these labels using a LabelMatchStatement
. For each label, provide a case-sensitive string containing optional namespaces and a label name, according to the following guidelines:- Separate each component of the label with a colon.
- Each namespace or name can have up to 128 characters.
- You can specify up to 5 namespaces in a label.
- Don’t use the following reserved words in your label specification:
aws
, waf
, managed
, rulegroup
, webacl
, regexpatternset
, or ipset
.
For example, myLabelName
or nameSpace1:nameSpace2:myLabelName
.
name
Type: STRING
Provider name: Name
Description: The label string.
statement
Type: STRUCT
Provider name: Statement
Description: The WAF processing statement for the rule, for example ByteMatchStatement or SizeConstraintStatement.
byte_match_statement
Type: STRUCT
Provider name: ByteMatchStatement
Description: A rule statement that defines a string match search for WAF to apply to web requests. The byte match statement provides the bytes to search for, the location in requests that you want WAF to search, and other settings. The bytes to search for are typically a string that corresponds with ASCII characters. In the WAF console and the developer guide, this is called a string match statement.
field_to_match
Type: STRUCT
Provider name: FieldToMatch
Description: The part of the web request that you want WAF to inspect.
all_query_arguments
Type: STRUCT
Provider name: AllQueryArguments
Description: Inspect all query arguments.
body
Type: STRUCT
Provider name: Body
Description: Inspect the request body as plain text. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the Body
object configuration.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
cookies
Type: STRUCT
Provider name: Cookies
Description: Inspect the request cookies. You must configure scope and pattern matching filters in the Cookies
object, to define the set of cookies and the parts of the cookies that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s cookies and only the first 200 cookies are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize cookie content in the Cookies
object. WAF applies the pattern matching filters to the cookies that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of cookies to inspect in a web request. You must specify exactly one setting: either All
, IncludedCookies
, or ExcludedCookies
. Example JSON: “MatchPattern”: { “IncludedCookies”: [ “session-id-time”, “session-id” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all cookies.
excluded_cookies
Type: UNORDERED_LIST_STRING
Provider name: ExcludedCookies
Description: Inspect only the cookies whose keys don’t match any of the strings specified here.
included_cookies
Type: UNORDERED_LIST_STRING
Provider name: IncludedCookies
Description: Inspect only the cookies that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the cookies to inspect with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the cookies of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request cookies when they exceed 8 KB (8192 bytes) or 200 total cookies. The underlying host service forwards a maximum of 200 cookies and at most 8 KB of cookie contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available cookies normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
header_order
Type: STRUCT
Provider name: HeaderOrder
Description: Inspect a string containing the list of the request’s header names, ordered as they appear in the web request that WAF receives for inspection. WAF generates the string and then uses that as the field to match component in its inspection. WAF separates the header names in the string using colons and no added spaces, for example host:user-agent:accept:authorization:referer
.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
headers
Type: STRUCT
Provider name: Headers
Description: Inspect the request headers. You must configure scope and pattern matching filters in the Headers
object, to define the set of headers to and the parts of the headers that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s headers and only the first 200 headers are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize header content in the Headers
object. WAF applies the pattern matching filters to the headers that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of headers to inspect in a web request. You must specify exactly one setting: either All
, IncludedHeaders
, or ExcludedHeaders
. Example JSON: “MatchPattern”: { “ExcludedHeaders”: [ “KeyToExclude1”, “KeyToExclude2” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all headers.
excluded_headers
Type: UNORDERED_LIST_STRING
Provider name: ExcludedHeaders
Description: Inspect only the headers whose keys don’t match any of the strings specified here.
included_headers
Type: UNORDERED_LIST_STRING
Provider name: IncludedHeaders
Description: Inspect only the headers that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the headers to match with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
ja3_fingerprint
Type: STRUCT
Provider name: JA3Fingerprint
Description: Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request’s JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client’s TLS configuration. WAF calculates and logs this fingerprint for each request that has enough TLS Client Hello information for the calculation. Almost all web requests include this information. You can use this choice only with a string match ByteMatchStatement
with the PositionalConstraint
set to EXACTLY
. You can obtain the JA3 fingerprint for client requests from the web ACL logs. If WAF is able to calculate the fingerprint, it includes it in the logs. For information about the logging fields, see Log fields in the WAF Developer Guide. Provide the JA3 fingerprint string from the logs in your string match statement specification, to match with any future requests that have the same TLS configuration.
fallback_behavior
Type: STRING
Provider name: FallbackBehavior
Description: The match status to assign to the web request if the request doesn’t have a JA3 fingerprint. You can specify the following fallback behaviors:MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
json_body
Type: STRUCT
Provider name: JsonBody
Description: Inspect the request body as JSON. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the JsonBody
object configuration.
invalid_fallback_behavior
Type: STRING
Provider name: InvalidFallbackBehavior
Description: What WAF should do if it fails to completely parse the JSON body. The options are the following:EVALUATE_AS_STRING
- Inspect the body as plain text. WAF applies the text transformations and inspection criteria that you defined for the JSON inspection to the body text string.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
If you don’t provide this setting, WAF parses and evaluates the content only up to the first parsing failure that it encounters. WAF parsing doesn’t fully validate the input JSON string, so parsing can succeed even for invalid JSON. When parsing succeeds, WAF doesn’t apply the fallback behavior. For more information, see JSON body in the WAF Developer Guide.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
all
Type: STRUCT
Provider name: All
Description: Match all of the elements. See also MatchScope
in JsonBody. You must specify either this setting or the IncludedPaths
setting, but not both.
included_paths
Type: UNORDERED_LIST_STRING
Provider name: IncludedPaths
Description: Match only the specified include paths. See also MatchScope
in JsonBody. Provide the include paths using JSON Pointer syntax. For example, “IncludedPaths”: ["/dogs/0/name", “/dogs/1/name”]
. For information about this syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. You must specify either this setting or the All
setting, but not both. Don’t use this option to include all paths. Instead, use the All
setting.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the JSON to match against using the MatchPattern
. If you specify ALL
, WAF matches against keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
method
Type: STRUCT
Provider name: Method
Description: Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
query_string
Type: STRUCT
Provider name: QueryString
Description: Inspect the query string. This is the part of a URL that appears after a ?
character, if any.
single_header
Type: STRUCT
Provider name: SingleHeader
Description: Inspect a single header. Provide the name of the header to inspect, for example, User-Agent
or Referer
. This setting isn’t case sensitive. Example JSON: “SingleHeader”: { “Name”: “haystack” }
Alternately, you can filter and inspect all headers with the Headers
FieldToMatch
setting.
name
Type: STRING
Provider name: Name
Description: The name of the query header to inspect.
single_query_argument
Type: STRUCT
Provider name: SingleQueryArgument
Description: Inspect a single query argument. Provide the name of the query argument to inspect, such as UserName or SalesRegion. The name can be up to 30 characters long and isn’t case sensitive. Example JSON: “SingleQueryArgument”: { “Name”: “myArgument” }
name
Type: STRING
Provider name: Name
Description: The name of the query argument to inspect.
uri_path
Type: STRUCT
Provider name: UriPath
Description: Inspect the request URI path. This is the part of the web request that identifies a resource, for example, /images/daily-ad.jpg
.
positional_constraint
Type: STRING
Provider name: PositionalConstraint
Description: The area within the portion of the web request that you want WAF to search for SearchString
. Valid values include the following: CONTAINS The specified part of the web request must include the value of SearchString
, but the location doesn’t matter. CONTAINS_WORD The specified part of the web request must include the value of SearchString
, and SearchString
must contain only alphanumeric characters or underscore (A-Z, a-z, 0-9, or ). In addition, SearchString
must be a word, which means that both of the following are true:SearchString
is at the beginning of the specified part of the web request or is preceded by a character other than an alphanumeric character or underscore (
). Examples include the value of a header and ;BadBot
.SearchString
is at the end of the specified part of the web request or is followed by a character other than an alphanumeric character or underscore (_), for example, BadBot;
and -BadBot;
.
EXACTLY The value of the specified part of the web request must exactly match the value of SearchString
. STARTS_WITH The value of SearchString
must appear at the beginning of the specified part of the web request. ENDS_WITH The value of SearchString
must appear at the end of the specified part of the web request.
text_transformations
Type: UNORDERED_LIST_STRUCT
Provider name: TextTransformations
Description: Text transformations eliminate some of the unusual formatting that attackers use in web requests in an effort to bypass detection. Text transformations are used in rule match statements, to transform the FieldToMatch
request component before inspecting it, and they’re used in rate-based rule statements, to transform request components before using them as custom aggregation keys. If you specify one or more transformations to apply, WAF performs all transformations on the specified content, starting from the lowest priority setting, and then uses the transformed component contents.
priority
Type: INT32
Provider name: Priority
Description: Sets the relative processing order for multiple transformations. WAF processes all transformations, from lowest priority to highest, before inspecting the transformed content. The priorities don’t need to be consecutive, but they must all be different.
type
Type: STRING
Provider name: Type
Description: For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
geo_match_statement
Type: STRUCT
Provider name: GeoMatchStatement
Description: A rule statement that labels web requests by country and region and that matches against web requests based on country code. A geo match rule labels every request that it inspects regardless of whether it finds a match.- To manage requests only by country, you can use this statement by itself and specify the countries that you want to match against in the
CountryCodes
array. - Otherwise, configure your geo match rule with Count action so that it only labels requests. Then, add one or more label match rules to run after the geo match rule and configure them to match against the geographic labels and handle the requests as needed.
WAF labels requests using the alpha-2 country and region codes from the International Organization for Standardization (ISO) 3166 standard. WAF determines the codes using either the IP address in the web request origin or, if you specify it, the address in the geo match ForwardedIPConfig
. If you use the web request origin, the label formats are awswaf:clientip:geo:region:<ISO country code>-<ISO region code>
and awswaf:clientip:geo:country:<ISO country code>
. If you use a forwarded IP address, the label formats are awswaf:forwardedip:geo:region:<ISO country code>-<ISO region code>
and awswaf:forwardedip:geo:country:<ISO country code>
. For additional details, see Geographic match rule statement in the WAF Developer Guide.
country_codes
Type: UNORDERED_LIST_STRING
Provider name: CountryCodes
Description: An array of two-character country codes that you want to match against, for example, [ “US”, “CN” ]
, from the alpha-2 country ISO codes of the ISO 3166 international standard. When you use a geo match statement just for the region and country labels that it adds to requests, you still have to supply a country code for the rule to evaluate. In this case, you configure the rule to only count matching requests, but it will still generate logging and count metrics for any matches. You can reduce the logging and metrics that the rule produces by specifying a country that’s unlikely to be a source of traffic to your site.
forwarded_ip_config
Type: STRUCT
Provider name: ForwardedIPConfig
Description: The configuration for inspecting IP addresses in an HTTP header that you specify, instead of using the IP address that’s reported by the web request origin. Commonly, this is the X-Forwarded-For (XFF) header, but you can specify any header name. If the specified header isn’t present in the request, WAF doesn’t apply the rule to the web request at all.
fallback_behavior
Type: STRING
Provider name: FallbackBehavior
Description: The match status to assign to the web request if the request doesn’t have a valid IP address in the specified position. If the specified header isn’t present in the request, WAF doesn’t apply the rule to the web request at all. You can specify the following fallback behaviors:MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
header_name
Type: STRING
Provider name: HeaderName
Description: The name of the HTTP header to use for the IP address. For example, to use the X-Forwarded-For (XFF) header, set this to X-Forwarded-For
. If the specified header isn’t present in the request, WAF doesn’t apply the rule to the web request at all.
ip_set_reference_statement
Type: STRUCT
Provider name: IPSetReferenceStatement
Description: A rule statement used to detect web requests coming from particular IP addresses or address ranges. To use this, create an IPSet that specifies the addresses you want to detect, then use the ARN of that set in this statement. To create an IP set, see CreateIPSet. Each IP set rule statement references an IP set. You create and maintain the set independent of your rules. This allows you to use the single set in multiple rules. When you update the referenced set, WAF automatically updates all rules that reference it.
arn
Type: STRING
Provider name: ARN
Description: The Amazon Resource Name (ARN) of the IPSet that this statement references.
ip_set_forwarded_ip_config
Type: STRUCT
Provider name: IPSetForwardedIPConfig
Description: The configuration for inspecting IP addresses in an HTTP header that you specify, instead of using the IP address that’s reported by the web request origin. Commonly, this is the X-Forwarded-For (XFF) header, but you can specify any header name. If the specified header isn’t present in the request, WAF doesn’t apply the rule to the web request at all.
fallback_behavior
Type: STRING
Provider name: FallbackBehavior
Description: The match status to assign to the web request if the request doesn’t have a valid IP address in the specified position. If the specified header isn’t present in the request, WAF doesn’t apply the rule to the web request at all. You can specify the following fallback behaviors:MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
header_name
Type: STRING
Provider name: HeaderName
Description: The name of the HTTP header to use for the IP address. For example, to use the X-Forwarded-For (XFF) header, set this to X-Forwarded-For
. If the specified header isn’t present in the request, WAF doesn’t apply the rule to the web request at all.
position
Type: STRING
Provider name: Position
Description: The position in the header to search for the IP address. The header can contain IP addresses of the original client and also of proxies. For example, the header value could be 10.1.1.1, 127.0.0.0, 10.10.10.10
where the first IP address identifies the original client and the rest identify proxies that the request went through. The options for this setting are the following:- FIRST - Inspect the first IP address in the list of IP addresses in the header. This is usually the client’s original IP.
- LAST - Inspect the last IP address in the list of IP addresses in the header.
- ANY - Inspect all IP addresses in the header for a match. If the header contains more than 10 IP addresses, WAF inspects the last 10.
label_match_statement
Type: STRUCT
Provider name: LabelMatchStatement
Description: A rule statement to match against labels that have been added to the web request by rules that have already run in the web ACL. The label match statement provides the label or namespace string to search for. The label string can represent a part or all of the fully qualified label name that had been added to the web request. Fully qualified labels have a prefix, optional namespaces, and label name. The prefix identifies the rule group or web ACL context of the rule that added the label. If you do not provide the fully qualified name in your label match string, WAF performs the search for labels that were added in the same context as the label match statement.
key
Type: STRING
Provider name: Key
Description: The string to match against. The setting you provide for this depends on the match statement’s Scope
setting:- If the
Scope
indicates LABEL
, then this specification must include the name and can include any number of preceding namespace specifications and prefix up to providing the fully qualified label name. - If the
Scope
indicates NAMESPACE
, then this specification can include any number of contiguous namespace strings, and can include the entire label namespace prefix from the rule group or web ACL where the label originates.
Labels are case sensitive and components of a label must be separated by colon, for example NS1:NS2:name
.
scope
Type: STRING
Provider name: Scope
Description: Specify whether you want to match using the label name or just the namespace.
managed_rule_group_statement
Type: STRUCT
Provider name: ManagedRuleGroupStatement
Description: A rule statement used to run the rules that are defined in a managed rule group. To use this, provide the vendor name and the name of the rule group in this statement. You can retrieve the required names by calling ListAvailableManagedRuleGroups. You cannot nest a ManagedRuleGroupStatement
, for example for use inside a NotStatement
or OrStatement
. You cannot use a managed rule group inside another rule group. You can only reference a managed rule group as a top-level statement within a rule that you define in a web ACL. You are charged additional fees when you use the WAF Bot Control managed rule group AWSManagedRulesBotControlRuleSet
, the WAF Fraud Control account takeover prevention (ATP) managed rule group AWSManagedRulesATPRuleSet
, or the WAF Fraud Control account creation fraud prevention (ACFP) managed rule group AWSManagedRulesACFPRuleSet
. For more information, see WAF Pricing.
excluded_rules
Type: UNORDERED_LIST_STRUCT
Provider name: ExcludedRules
Description: Rules in the referenced rule group whose actions are set to Count
. Instead of this option, use RuleActionOverrides
. It accepts any valid action setting, including Count
.
name
Type: STRING
Provider name: Name
Description: The name of the rule whose action you want to override to Count
.
managed_rule_group_configs
Type: UNORDERED_LIST_STRUCT
Provider name: ManagedRuleGroupConfigs
Description: Additional information that’s used by a managed rule group. Many managed rule groups don’t require this. The rule groups used for intelligent threat mitigation require additional configuration:- Use the
AWSManagedRulesACFPRuleSet
configuration object to configure the account creation fraud prevention managed rule group. The configuration includes the registration and sign-up pages of your application and the locations in the account creation request payload of data, such as the user email and phone number fields. - Use the
AWSManagedRulesATPRuleSet
configuration object to configure the account takeover prevention managed rule group. The configuration includes the sign-in page of your application and the locations in the login request payload of data such as the username and password. - Use the
AWSManagedRulesBotControlRuleSet
configuration object to configure the protection level that you want the Bot Control rule group to use.
aws_managed_rules_acfp_rule_set
Type: STRUCT
Provider name: AWSManagedRulesACFPRuleSet
Description: Additional configuration for using the account creation fraud prevention (ACFP) managed rule group, AWSManagedRulesACFPRuleSet
. Use this to provide account creation request information to the rule group. For web ACLs that protect CloudFront distributions, use this to also provide the information about how your distribution responds to account creation requests. For information about using the ACFP managed rule group, see WAF Fraud Control account creation fraud prevention (ACFP) rule group and WAF Fraud Control account creation fraud prevention (ACFP) in the WAF Developer Guide.
creation_path
Type: STRING
Provider name: CreationPath
Description: The path of the account creation endpoint for your application. This is the page on your website that accepts the completed registration form for a new user. This page must accept POST
requests. For example, for the URL https://example.com/web/newaccount
, you would provide the path /web/newaccount
. Account creation page paths that start with the path that you provide are considered a match. For example /web/newaccount
matches the account creation paths /web/newaccount
, /web/newaccount/
, /web/newaccountPage
, and /web/newaccount/thisPage
, but doesn’t match the path /home/web/newaccount
or /website/newaccount
.
enable_regex_in_path
Type: BOOLEAN
Provider name: EnableRegexInPath
Description: Allow the use of regular expressions in the registration page path and the account creation path.
registration_page_path
Type: STRING
Provider name: RegistrationPagePath
Description: The path of the account registration endpoint for your application. This is the page on your website that presents the registration form to new users. This page must accept GET
text/html requests. For example, for the URL https://example.com/web/registration
, you would provide the path /web/registration
. Registration page paths that start with the path that you provide are considered a match. For example /web/registration
matches the registration paths /web/registration
, /web/registration/
, /web/registrationPage
, and /web/registration/thisPage
, but doesn’t match the path /home/web/registration
or /website/registration
.
request_inspection
Type: STRUCT
Provider name: RequestInspection
Description: The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
address_fields
Type: UNORDERED_LIST_STRUCT
Provider name: AddressFields
Description: The names of the fields in the request payload that contain your customer’s primary physical address. Order the address fields in the array exactly as they are ordered in the request payload. How you specify the address fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryaddressline1”: “THE_ADDRESS1”, “primaryaddressline2”: “THE_ADDRESS2”, “primaryaddressline3”: “THE_ADDRESS3” } }
, the address field idenfiers are /form/primaryaddressline1
, /form/primaryaddressline2
, and /form/primaryaddressline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
, the address fields identifiers are primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of a single primary address field. How you specify the address fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryaddressline1”: “THE_ADDRESS1”, “primaryaddressline2”: “THE_ADDRESS2”, “primaryaddressline3”: “THE_ADDRESS3” } }
, the address field idenfiers are /form/primaryaddressline1
, /form/primaryaddressline2
, and /form/primaryaddressline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
, the address fields identifiers are primaryaddressline1
, primaryaddressline2
, and primaryaddressline3
.
email_field
Type: STRUCT
Provider name: EmailField
Description: The name of the field in the request payload that contains your customer’s email. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “email”: “THE_EMAIL” } }
, the email field specification is /form/email
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
email1
, the email field specification is email1
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the email field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “email”: “THE_EMAIL” } }
, the email field specification is /form/email
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
email1
, the email field specification is email1
.
password_field
Type: STRUCT
Provider name: PasswordField
Description: The name of the field in the request payload that contains your customer’s password. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the password field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
payload_type
Type: STRING
Provider name: PayloadType
Description: The payload type for your account creation endpoint, either JSON or form encoded.
phone_number_fields
Type: UNORDERED_LIST_STRUCT
Provider name: PhoneNumberFields
Description: The names of the fields in the request payload that contain your customer’s primary phone number. Order the phone number fields in the array exactly as they are ordered in the request payload. How you specify the phone number fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryphoneline1”: “THE_PHONE1”, “primaryphoneline2”: “THE_PHONE2”, “primaryphoneline3”: “THE_PHONE3” } }
, the phone number field identifiers are /form/primaryphoneline1
, /form/primaryphoneline2
, and /form/primaryphoneline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
, the phone number field identifiers are primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of a single primary phone number field. How you specify the phone number fields depends on the request inspection payload type.- For JSON payloads, specify the field identifiers in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “primaryphoneline1”: “THE_PHONE1”, “primaryphoneline2”: “THE_PHONE2”, “primaryphoneline3”: “THE_PHONE3” } }
, the phone number field identifiers are /form/primaryphoneline1
, /form/primaryphoneline2
, and /form/primaryphoneline3
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with input elements named
primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
, the phone number field identifiers are primaryphoneline1
, primaryphoneline2
, and primaryphoneline3
.
username_field
Type: STRUCT
Provider name: UsernameField
Description: The name of the field in the request payload that contains your customer’s username. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
identifier
Type: STRING
Provider name: Identifier
Description: The name of the username field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
response_inspection
Type: STRUCT
Provider name: ResponseInspection
Description: The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates. Response inspection is available only in web ACLs that protect Amazon CloudFront distributions. The ACFP rule group evaluates the responses that your protected resources send back to client account creation attempts, keeping count of successful and failed attempts from each IP address and client session. Using this information, the rule group labels and mitigates requests from client sessions and IP addresses that have had too many successful account creation attempts in a short amount of time.
body_contains
Type: STRUCT
Provider name: BodyContains
Description: Configures inspection of the response body for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response body.
failure_strings
Type: UNORDERED_LIST_STRING
Provider name: FailureStrings
Description: Strings in the body of the response that indicate a failed login or account creation attempt. To be counted as a failure, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON example: “FailureStrings”: [ “Request failed” ]
success_strings
Type: UNORDERED_LIST_STRING
Provider name: SuccessStrings
Description: Strings in the body of the response that indicate a successful login or account creation attempt. To be counted as a success, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON examples: “SuccessStrings”: [ “Login successful” ]
and “SuccessStrings”: [ “Account creation successful”, “Welcome to our site!” ]
header
Type: STRUCT
Provider name: Header
Description: Configures inspection of the response header for success and failure indicators.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values in the response header with the specified name that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “FailureValues”: [ “LoginFailed”, “Failed login” ]
and “FailureValues”: [ “AccountCreationFailed” ]
name
Type: STRING
Provider name: Name
Description: The name of the header to match against. The name must be an exact match, including case. JSON example: “Name”: [ “RequestResult” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values in the response header with the specified name that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “SuccessValues”: [ “LoginPassed”, “Successful login” ]
and “SuccessValues”: [ “AccountCreated”, “Successful account creation” ]
json
Type: STRUCT
Provider name: Json
Description: Configures inspection of the response JSON for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response JSON.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values for the specified identifier in the response JSON that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “FailureValues”: [ “False”, “Failed” ]
identifier
Type: STRING
Provider name: Identifier
Description: The identifier for the value to match against in the JSON. The identifier must be an exact match, including case. JSON examples: “Identifier”: [ “/login/success” ]
and “Identifier”: [ “/sign-up/success” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values for the specified identifier in the response JSON that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “SuccessValues”: [ “True”, “Succeeded” ]
status_code
Type: STRUCT
Provider name: StatusCode
Description: Configures inspection of the response status code for success and failure indicators.
failure_codes
Type: UNORDERED_LIST_INT32
Provider name: FailureCodes
Description: Status codes in the response that indicate a failed login or account creation attempt. To be counted as a failure, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “FailureCodes”: [ 400, 404 ]
success_codes
Type: UNORDERED_LIST_INT32
Provider name: SuccessCodes
Description: Status codes in the response that indicate a successful login or account creation attempt. To be counted as a success, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “SuccessCodes”: [ 200, 201 ]
aws_managed_rules_atp_rule_set
Type: STRUCT
Provider name: AWSManagedRulesATPRuleSet
Description: Additional configuration for using the account takeover prevention (ATP) managed rule group, AWSManagedRulesATPRuleSet
. Use this to provide login request information to the rule group. For web ACLs that protect CloudFront distributions, use this to also provide the information about how your distribution responds to login requests. This configuration replaces the individual configuration fields in ManagedRuleGroupConfig
and provides additional feature configuration. For information about using the ATP managed rule group, see WAF Fraud Control account takeover prevention (ATP) rule group and WAF Fraud Control account takeover prevention (ATP) in the WAF Developer Guide.
enable_regex_in_path
Type: BOOLEAN
Provider name: EnableRegexInPath
Description: Allow the use of regular expressions in the login page path.
login_path
Type: STRING
Provider name: LoginPath
Description: The path of the login endpoint for your application. For example, for the URL https://example.com/web/login
, you would provide the path /web/login
. Login paths that start with the path that you provide are considered a match. For example /web/login
matches the login paths /web/login
, /web/login/
, /web/loginPage
, and /web/login/thisPage
, but doesn’t match the login path /home/web/login
or /website/login
. The rule group inspects only HTTP POST
requests to your specified login endpoint.
request_inspection
Type: STRUCT
Provider name: RequestInspection
Description: The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
password_field
Type: STRUCT
Provider name: PasswordField
Description: The name of the field in the request payload that contains your customer’s password. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the password field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
payload_type
Type: STRING
Provider name: PayloadType
Description: The payload type for your login endpoint, either JSON or form encoded.
username_field
Type: STRUCT
Provider name: UsernameField
Description: The name of the field in the request payload that contains your customer’s username. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
identifier
Type: STRING
Provider name: Identifier
Description: The name of the username field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
response_inspection
Type: STRUCT
Provider name: ResponseInspection
Description: The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates. Response inspection is available only in web ACLs that protect Amazon CloudFront distributions. The ATP rule group evaluates the responses that your protected resources send back to client login attempts, keeping count of successful and failed attempts for each IP address and client session. Using this information, the rule group labels and mitigates requests from client sessions and IP addresses that have had too many failed login attempts in a short amount of time.
body_contains
Type: STRUCT
Provider name: BodyContains
Description: Configures inspection of the response body for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response body.
failure_strings
Type: UNORDERED_LIST_STRING
Provider name: FailureStrings
Description: Strings in the body of the response that indicate a failed login or account creation attempt. To be counted as a failure, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON example: “FailureStrings”: [ “Request failed” ]
success_strings
Type: UNORDERED_LIST_STRING
Provider name: SuccessStrings
Description: Strings in the body of the response that indicate a successful login or account creation attempt. To be counted as a success, the string can be anywhere in the body and must be an exact match, including case. Each string must be unique among the success and failure strings. JSON examples: “SuccessStrings”: [ “Login successful” ]
and “SuccessStrings”: [ “Account creation successful”, “Welcome to our site!” ]
header
Type: STRUCT
Provider name: Header
Description: Configures inspection of the response header for success and failure indicators.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values in the response header with the specified name that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “FailureValues”: [ “LoginFailed”, “Failed login” ]
and “FailureValues”: [ “AccountCreationFailed” ]
name
Type: STRING
Provider name: Name
Description: The name of the header to match against. The name must be an exact match, including case. JSON example: “Name”: [ “RequestResult” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values in the response header with the specified name that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON examples: “SuccessValues”: [ “LoginPassed”, “Successful login” ]
and “SuccessValues”: [ “AccountCreated”, “Successful account creation” ]
json
Type: STRUCT
Provider name: Json
Description: Configures inspection of the response JSON for success and failure indicators. WAF can inspect the first 65,536 bytes (64 KB) of the response JSON.
failure_values
Type: UNORDERED_LIST_STRING
Provider name: FailureValues
Description: Values for the specified identifier in the response JSON that indicate a failed login or account creation attempt. To be counted as a failure, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “FailureValues”: [ “False”, “Failed” ]
identifier
Type: STRING
Provider name: Identifier
Description: The identifier for the value to match against in the JSON. The identifier must be an exact match, including case. JSON examples: “Identifier”: [ “/login/success” ]
and “Identifier”: [ “/sign-up/success” ]
success_values
Type: UNORDERED_LIST_STRING
Provider name: SuccessValues
Description: Values for the specified identifier in the response JSON that indicate a successful login or account creation attempt. To be counted as a success, the value must be an exact match, including case. Each value must be unique among the success and failure values. JSON example: “SuccessValues”: [ “True”, “Succeeded” ]
status_code
Type: STRUCT
Provider name: StatusCode
Description: Configures inspection of the response status code for success and failure indicators.
failure_codes
Type: UNORDERED_LIST_INT32
Provider name: FailureCodes
Description: Status codes in the response that indicate a failed login or account creation attempt. To be counted as a failure, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “FailureCodes”: [ 400, 404 ]
success_codes
Type: UNORDERED_LIST_INT32
Provider name: SuccessCodes
Description: Status codes in the response that indicate a successful login or account creation attempt. To be counted as a success, the response status code must match one of these. Each code must be unique among the success and failure status codes. JSON example: “SuccessCodes”: [ 200, 201 ]
aws_managed_rules_bot_control_rule_set
Type: STRUCT
Provider name: AWSManagedRulesBotControlRuleSet
Description: Additional configuration for using the Bot Control managed rule group. Use this to specify the inspection level that you want to use. For information about using the Bot Control managed rule group, see WAF Bot Control rule group and WAF Bot Control in the WAF Developer Guide.
enable_machine_learning
Type: BOOLEAN
Provider name: EnableMachineLearning
Description: Applies only to the targeted inspection level. Determines whether to use machine learning (ML) to analyze your web traffic for bot-related activity. Machine learning is required for the Bot Control rules TGT_ML_CoordinatedActivityLow
and TGT_ML_CoordinatedActivityMedium
, which inspect for anomalous behavior that might indicate distributed, coordinated bot activity. For more information about this choice, see the listing for these rules in the table at Bot Control rules listing in the WAF Developer Guide.
Default: TRUE
inspection_level
Type: STRING
Provider name: InspectionLevel
Description: The inspection level to use for the Bot Control rule group. The common level is the least expensive. The targeted level includes all common level rules and adds rules with more advanced inspection criteria. For details, see WAF Bot Control rule group in the WAF Developer Guide.
login_path
Type: STRING
Provider name: LoginPath
Description: Instead of this setting, provide your configuration under AWSManagedRulesATPRuleSet
.
password_field
Type: STRUCT
Provider name: PasswordField
Description: Instead of this setting, provide your configuration under the request inspection configuration for AWSManagedRulesATPRuleSet
or AWSManagedRulesACFPRuleSet
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the password field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “password”: “THE_PASSWORD” } }
, the password field specification is /form/password
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
password1
, the password field specification is password1
.
payload_type
Type: STRING
Provider name: PayloadType
Description: Instead of this setting, provide your configuration under the request inspection configuration for AWSManagedRulesATPRuleSet
or AWSManagedRulesACFPRuleSet
.
username_field
Type: STRUCT
Provider name: UsernameField
Description: Instead of this setting, provide your configuration under the request inspection configuration for AWSManagedRulesATPRuleSet
or AWSManagedRulesACFPRuleSet
.
identifier
Type: STRING
Provider name: Identifier
Description: The name of the username field. How you specify this depends on the request inspection payload type.- For JSON payloads, specify the field name in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. For example, for the JSON payload
{ “form”: { “username”: “THE_USERNAME” } }
, the username field specification is /form/username
. - For form encoded payload types, use the HTML form names. For example, for an HTML form with the input element named
username1
, the username field specification is username1
name
Type: STRING
Provider name: Name
Description: The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
rule_action_overrides
Type: UNORDERED_LIST_STRUCT
Provider name: RuleActionOverrides
Description: Action settings to use in the place of the rule actions that are configured inside the rule group. You specify one override for each rule whose action you want to change. You can use overrides for testing, for example you can override all of rule actions to Count
and then monitor the resulting count metrics to understand how the rule group would handle your web traffic. You can also permanently override some or all actions, to modify how the rule group manages your web traffic.
action_to_use
Type: STRUCT
Provider name: ActionToUse
Description: The override action to use, in place of the configured action of the rule in the rule group.
allow
Type: STRUCT
Provider name: Allow
Description: Instructs WAF to allow the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
block
Type: STRUCT
Provider name: Block
Description: Instructs WAF to block the web request.
custom_response
Type: STRUCT
Provider name: CustomResponse
Description: Defines a custom response for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
custom_response_body_key
Type: STRING
Provider name: CustomResponseBodyKey
Description: References the response body that you want WAF to return to the web request client. You can define a custom response for a rule action or a default web ACL action that is set to block. To do this, you first define the response body key and value in the CustomResponseBodies
setting for the WebACL or RuleGroup where you want to use it. Then, in the rule action or web ACL default action BlockAction
setting, you reference the response body using this key.
response_code
Type: INT32
Provider name: ResponseCode
Description: The HTTP status code to return to the client. For a list of status codes that you can use in your custom responses, see Supported status codes for custom response in the WAF Developer Guide.
response_headers
Type: UNORDERED_LIST_STRUCT
Provider name: ResponseHeaders
Description: The HTTP headers to use in the response. You can specify any header name except for content-type
. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
captcha
Type: STRUCT
Provider name: Captcha
Description: Instructs WAF to run a CAPTCHA
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the CAPTCHA
inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
challenge
Type: STRUCT
Provider name: Challenge
Description: Instructs WAF to run a Challenge
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the challenge inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
count
Type: STRUCT
Provider name: Count
Description: Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
name
Type: STRING
Provider name: Name
Description: The name of the rule to override.
vendor_name
Type: STRING
Provider name: VendorName
Description: The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
version
Type: STRING
Provider name: Version
Description: The version of the managed rule group to use. If you specify this, the version setting is fixed until you change it. If you don’t specify this, WAF uses the vendor’s default version, and then keeps the version at the vendor’s default when the vendor updates the managed rule group settings.
regex_match_statement
Type: STRUCT
Provider name: RegexMatchStatement
Description: A rule statement used to search web request components for a match against a single regular expression.
field_to_match
Type: STRUCT
Provider name: FieldToMatch
Description: The part of the web request that you want WAF to inspect.
all_query_arguments
Type: STRUCT
Provider name: AllQueryArguments
Description: Inspect all query arguments.
body
Type: STRUCT
Provider name: Body
Description: Inspect the request body as plain text. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the Body
object configuration.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
cookies
Type: STRUCT
Provider name: Cookies
Description: Inspect the request cookies. You must configure scope and pattern matching filters in the Cookies
object, to define the set of cookies and the parts of the cookies that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s cookies and only the first 200 cookies are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize cookie content in the Cookies
object. WAF applies the pattern matching filters to the cookies that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of cookies to inspect in a web request. You must specify exactly one setting: either All
, IncludedCookies
, or ExcludedCookies
. Example JSON: “MatchPattern”: { “IncludedCookies”: [ “session-id-time”, “session-id” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all cookies.
excluded_cookies
Type: UNORDERED_LIST_STRING
Provider name: ExcludedCookies
Description: Inspect only the cookies whose keys don’t match any of the strings specified here.
included_cookies
Type: UNORDERED_LIST_STRING
Provider name: IncludedCookies
Description: Inspect only the cookies that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the cookies to inspect with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the cookies of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request cookies when they exceed 8 KB (8192 bytes) or 200 total cookies. The underlying host service forwards a maximum of 200 cookies and at most 8 KB of cookie contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available cookies normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
header_order
Type: STRUCT
Provider name: HeaderOrder
Description: Inspect a string containing the list of the request’s header names, ordered as they appear in the web request that WAF receives for inspection. WAF generates the string and then uses that as the field to match component in its inspection. WAF separates the header names in the string using colons and no added spaces, for example host:user-agent:accept:authorization:referer
.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
headers
Type: STRUCT
Provider name: Headers
Description: Inspect the request headers. You must configure scope and pattern matching filters in the Headers
object, to define the set of headers to and the parts of the headers that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s headers and only the first 200 headers are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize header content in the Headers
object. WAF applies the pattern matching filters to the headers that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of headers to inspect in a web request. You must specify exactly one setting: either All
, IncludedHeaders
, or ExcludedHeaders
. Example JSON: “MatchPattern”: { “ExcludedHeaders”: [ “KeyToExclude1”, “KeyToExclude2” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all headers.
excluded_headers
Type: UNORDERED_LIST_STRING
Provider name: ExcludedHeaders
Description: Inspect only the headers whose keys don’t match any of the strings specified here.
included_headers
Type: UNORDERED_LIST_STRING
Provider name: IncludedHeaders
Description: Inspect only the headers that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the headers to match with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
ja3_fingerprint
Type: STRUCT
Provider name: JA3Fingerprint
Description: Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request’s JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client’s TLS configuration. WAF calculates and logs this fingerprint for each request that has enough TLS Client Hello information for the calculation. Almost all web requests include this information. You can use this choice only with a string match ByteMatchStatement
with the PositionalConstraint
set to EXACTLY
. You can obtain the JA3 fingerprint for client requests from the web ACL logs. If WAF is able to calculate the fingerprint, it includes it in the logs. For information about the logging fields, see Log fields in the WAF Developer Guide. Provide the JA3 fingerprint string from the logs in your string match statement specification, to match with any future requests that have the same TLS configuration.
fallback_behavior
Type: STRING
Provider name: FallbackBehavior
Description: The match status to assign to the web request if the request doesn’t have a JA3 fingerprint. You can specify the following fallback behaviors:MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
json_body
Type: STRUCT
Provider name: JsonBody
Description: Inspect the request body as JSON. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the JsonBody
object configuration.
invalid_fallback_behavior
Type: STRING
Provider name: InvalidFallbackBehavior
Description: What WAF should do if it fails to completely parse the JSON body. The options are the following:EVALUATE_AS_STRING
- Inspect the body as plain text. WAF applies the text transformations and inspection criteria that you defined for the JSON inspection to the body text string.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
If you don’t provide this setting, WAF parses and evaluates the content only up to the first parsing failure that it encounters. WAF parsing doesn’t fully validate the input JSON string, so parsing can succeed even for invalid JSON. When parsing succeeds, WAF doesn’t apply the fallback behavior. For more information, see JSON body in the WAF Developer Guide.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
all
Type: STRUCT
Provider name: All
Description: Match all of the elements. See also MatchScope
in JsonBody. You must specify either this setting or the IncludedPaths
setting, but not both.
included_paths
Type: UNORDERED_LIST_STRING
Provider name: IncludedPaths
Description: Match only the specified include paths. See also MatchScope
in JsonBody. Provide the include paths using JSON Pointer syntax. For example, “IncludedPaths”: ["/dogs/0/name", “/dogs/1/name”]
. For information about this syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. You must specify either this setting or the All
setting, but not both. Don’t use this option to include all paths. Instead, use the All
setting.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the JSON to match against using the MatchPattern
. If you specify ALL
, WAF matches against keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
method
Type: STRUCT
Provider name: Method
Description: Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
query_string
Type: STRUCT
Provider name: QueryString
Description: Inspect the query string. This is the part of a URL that appears after a ?
character, if any.
single_header
Type: STRUCT
Provider name: SingleHeader
Description: Inspect a single header. Provide the name of the header to inspect, for example, User-Agent
or Referer
. This setting isn’t case sensitive. Example JSON: “SingleHeader”: { “Name”: “haystack” }
Alternately, you can filter and inspect all headers with the Headers
FieldToMatch
setting.
name
Type: STRING
Provider name: Name
Description: The name of the query header to inspect.
single_query_argument
Type: STRUCT
Provider name: SingleQueryArgument
Description: Inspect a single query argument. Provide the name of the query argument to inspect, such as UserName or SalesRegion. The name can be up to 30 characters long and isn’t case sensitive. Example JSON: “SingleQueryArgument”: { “Name”: “myArgument” }
name
Type: STRING
Provider name: Name
Description: The name of the query argument to inspect.
uri_path
Type: STRUCT
Provider name: UriPath
Description: Inspect the request URI path. This is the part of the web request that identifies a resource, for example, /images/daily-ad.jpg
.
regex_string
Type: STRING
Provider name: RegexString
Description: The string representing the regular expression.
text_transformations
Type: UNORDERED_LIST_STRUCT
Provider name: TextTransformations
Description: Text transformations eliminate some of the unusual formatting that attackers use in web requests in an effort to bypass detection. Text transformations are used in rule match statements, to transform the FieldToMatch
request component before inspecting it, and they’re used in rate-based rule statements, to transform request components before using them as custom aggregation keys. If you specify one or more transformations to apply, WAF performs all transformations on the specified content, starting from the lowest priority setting, and then uses the transformed component contents.
priority
Type: INT32
Provider name: Priority
Description: Sets the relative processing order for multiple transformations. WAF processes all transformations, from lowest priority to highest, before inspecting the transformed content. The priorities don’t need to be consecutive, but they must all be different.
type
Type: STRING
Provider name: Type
Description: For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
regex_pattern_set_reference_statement
Type: STRUCT
Provider name: RegexPatternSetReferenceStatement
Description: A rule statement used to search web request components for matches with regular expressions. To use this, create a RegexPatternSet that specifies the expressions that you want to detect, then use the ARN of that set in this statement. A web request matches the pattern set rule statement if the request component matches any of the patterns in the set. To create a regex pattern set, see CreateRegexPatternSet. Each regex pattern set rule statement references a regex pattern set. You create and maintain the set independent of your rules. This allows you to use the single set in multiple rules. When you update the referenced set, WAF automatically updates all rules that reference it.
arn
Type: STRING
Provider name: ARN
Description: The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
field_to_match
Type: STRUCT
Provider name: FieldToMatch
Description: The part of the web request that you want WAF to inspect.
all_query_arguments
Type: STRUCT
Provider name: AllQueryArguments
Description: Inspect all query arguments.
body
Type: STRUCT
Provider name: Body
Description: Inspect the request body as plain text. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the Body
object configuration.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
cookies
Type: STRUCT
Provider name: Cookies
Description: Inspect the request cookies. You must configure scope and pattern matching filters in the Cookies
object, to define the set of cookies and the parts of the cookies that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s cookies and only the first 200 cookies are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize cookie content in the Cookies
object. WAF applies the pattern matching filters to the cookies that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of cookies to inspect in a web request. You must specify exactly one setting: either All
, IncludedCookies
, or ExcludedCookies
. Example JSON: “MatchPattern”: { “IncludedCookies”: [ “session-id-time”, “session-id” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all cookies.
excluded_cookies
Type: UNORDERED_LIST_STRING
Provider name: ExcludedCookies
Description: Inspect only the cookies whose keys don’t match any of the strings specified here.
included_cookies
Type: UNORDERED_LIST_STRING
Provider name: IncludedCookies
Description: Inspect only the cookies that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the cookies to inspect with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the cookies of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request cookies when they exceed 8 KB (8192 bytes) or 200 total cookies. The underlying host service forwards a maximum of 200 cookies and at most 8 KB of cookie contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available cookies normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
header_order
Type: STRUCT
Provider name: HeaderOrder
Description: Inspect a string containing the list of the request’s header names, ordered as they appear in the web request that WAF receives for inspection. WAF generates the string and then uses that as the field to match component in its inspection. WAF separates the header names in the string using colons and no added spaces, for example host:user-agent:accept:authorization:referer
.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
headers
Type: STRUCT
Provider name: Headers
Description: Inspect the request headers. You must configure scope and pattern matching filters in the Headers
object, to define the set of headers to and the parts of the headers that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s headers and only the first 200 headers are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize header content in the Headers
object. WAF applies the pattern matching filters to the headers that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of headers to inspect in a web request. You must specify exactly one setting: either All
, IncludedHeaders
, or ExcludedHeaders
. Example JSON: “MatchPattern”: { “ExcludedHeaders”: [ “KeyToExclude1”, “KeyToExclude2” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all headers.
excluded_headers
Type: UNORDERED_LIST_STRING
Provider name: ExcludedHeaders
Description: Inspect only the headers whose keys don’t match any of the strings specified here.
included_headers
Type: UNORDERED_LIST_STRING
Provider name: IncludedHeaders
Description: Inspect only the headers that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the headers to match with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
ja3_fingerprint
Type: STRUCT
Provider name: JA3Fingerprint
Description: Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request’s JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client’s TLS configuration. WAF calculates and logs this fingerprint for each request that has enough TLS Client Hello information for the calculation. Almost all web requests include this information. You can use this choice only with a string match ByteMatchStatement
with the PositionalConstraint
set to EXACTLY
. You can obtain the JA3 fingerprint for client requests from the web ACL logs. If WAF is able to calculate the fingerprint, it includes it in the logs. For information about the logging fields, see Log fields in the WAF Developer Guide. Provide the JA3 fingerprint string from the logs in your string match statement specification, to match with any future requests that have the same TLS configuration.
fallback_behavior
Type: STRING
Provider name: FallbackBehavior
Description: The match status to assign to the web request if the request doesn’t have a JA3 fingerprint. You can specify the following fallback behaviors:MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
json_body
Type: STRUCT
Provider name: JsonBody
Description: Inspect the request body as JSON. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the JsonBody
object configuration.
invalid_fallback_behavior
Type: STRING
Provider name: InvalidFallbackBehavior
Description: What WAF should do if it fails to completely parse the JSON body. The options are the following:EVALUATE_AS_STRING
- Inspect the body as plain text. WAF applies the text transformations and inspection criteria that you defined for the JSON inspection to the body text string.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
If you don’t provide this setting, WAF parses and evaluates the content only up to the first parsing failure that it encounters. WAF parsing doesn’t fully validate the input JSON string, so parsing can succeed even for invalid JSON. When parsing succeeds, WAF doesn’t apply the fallback behavior. For more information, see JSON body in the WAF Developer Guide.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
all
Type: STRUCT
Provider name: All
Description: Match all of the elements. See also MatchScope
in JsonBody. You must specify either this setting or the IncludedPaths
setting, but not both.
included_paths
Type: UNORDERED_LIST_STRING
Provider name: IncludedPaths
Description: Match only the specified include paths. See also MatchScope
in JsonBody. Provide the include paths using JSON Pointer syntax. For example, “IncludedPaths”: ["/dogs/0/name", “/dogs/1/name”]
. For information about this syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. You must specify either this setting or the All
setting, but not both. Don’t use this option to include all paths. Instead, use the All
setting.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the JSON to match against using the MatchPattern
. If you specify ALL
, WAF matches against keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
method
Type: STRUCT
Provider name: Method
Description: Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
query_string
Type: STRUCT
Provider name: QueryString
Description: Inspect the query string. This is the part of a URL that appears after a ?
character, if any.
single_header
Type: STRUCT
Provider name: SingleHeader
Description: Inspect a single header. Provide the name of the header to inspect, for example, User-Agent
or Referer
. This setting isn’t case sensitive. Example JSON: “SingleHeader”: { “Name”: “haystack” }
Alternately, you can filter and inspect all headers with the Headers
FieldToMatch
setting.
name
Type: STRING
Provider name: Name
Description: The name of the query header to inspect.
single_query_argument
Type: STRUCT
Provider name: SingleQueryArgument
Description: Inspect a single query argument. Provide the name of the query argument to inspect, such as UserName or SalesRegion. The name can be up to 30 characters long and isn’t case sensitive. Example JSON: “SingleQueryArgument”: { “Name”: “myArgument” }
name
Type: STRING
Provider name: Name
Description: The name of the query argument to inspect.
uri_path
Type: STRUCT
Provider name: UriPath
Description: Inspect the request URI path. This is the part of the web request that identifies a resource, for example, /images/daily-ad.jpg
.
text_transformations
Type: UNORDERED_LIST_STRUCT
Provider name: TextTransformations
Description: Text transformations eliminate some of the unusual formatting that attackers use in web requests in an effort to bypass detection. Text transformations are used in rule match statements, to transform the FieldToMatch
request component before inspecting it, and they’re used in rate-based rule statements, to transform request components before using them as custom aggregation keys. If you specify one or more transformations to apply, WAF performs all transformations on the specified content, starting from the lowest priority setting, and then uses the transformed component contents.
priority
Type: INT32
Provider name: Priority
Description: Sets the relative processing order for multiple transformations. WAF processes all transformations, from lowest priority to highest, before inspecting the transformed content. The priorities don’t need to be consecutive, but they must all be different.
type
Type: STRING
Provider name: Type
Description: For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
rule_group_reference_statement
Type: STRUCT
Provider name: RuleGroupReferenceStatement
Description: A rule statement used to run the rules that are defined in a RuleGroup. To use this, create a rule group with your rules, then provide the ARN of the rule group in this statement. You cannot nest a RuleGroupReferenceStatement
, for example for use inside a NotStatement
or OrStatement
. You cannot use a rule group reference statement inside another rule group. You can only reference a rule group as a top-level statement within a rule that you define in a web ACL.
arn
Type: STRING
Provider name: ARN
Description: The Amazon Resource Name (ARN) of the entity.
excluded_rules
Type: UNORDERED_LIST_STRUCT
Provider name: ExcludedRules
Description: Rules in the referenced rule group whose actions are set to Count
. Instead of this option, use RuleActionOverrides
. It accepts any valid action setting, including Count
.
name
Type: STRING
Provider name: Name
Description: The name of the rule whose action you want to override to Count
.
rule_action_overrides
Type: UNORDERED_LIST_STRUCT
Provider name: RuleActionOverrides
Description: Action settings to use in the place of the rule actions that are configured inside the rule group. You specify one override for each rule whose action you want to change. You can use overrides for testing, for example you can override all of rule actions to Count
and then monitor the resulting count metrics to understand how the rule group would handle your web traffic. You can also permanently override some or all actions, to modify how the rule group manages your web traffic.
action_to_use
Type: STRUCT
Provider name: ActionToUse
Description: The override action to use, in place of the configured action of the rule in the rule group.
allow
Type: STRUCT
Provider name: Allow
Description: Instructs WAF to allow the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
block
Type: STRUCT
Provider name: Block
Description: Instructs WAF to block the web request.
custom_response
Type: STRUCT
Provider name: CustomResponse
Description: Defines a custom response for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
custom_response_body_key
Type: STRING
Provider name: CustomResponseBodyKey
Description: References the response body that you want WAF to return to the web request client. You can define a custom response for a rule action or a default web ACL action that is set to block. To do this, you first define the response body key and value in the CustomResponseBodies
setting for the WebACL or RuleGroup where you want to use it. Then, in the rule action or web ACL default action BlockAction
setting, you reference the response body using this key.
response_code
Type: INT32
Provider name: ResponseCode
Description: The HTTP status code to return to the client. For a list of status codes that you can use in your custom responses, see Supported status codes for custom response in the WAF Developer Guide.
response_headers
Type: UNORDERED_LIST_STRUCT
Provider name: ResponseHeaders
Description: The HTTP headers to use in the response. You can specify any header name except for content-type
. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
captcha
Type: STRUCT
Provider name: Captcha
Description: Instructs WAF to run a CAPTCHA
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the CAPTCHA
inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
challenge
Type: STRUCT
Provider name: Challenge
Description: Instructs WAF to run a Challenge
check against the web request.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request, used when the challenge inspection determines that the request’s token is valid and unexpired. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
count
Type: STRUCT
Provider name: Count
Description: Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
custom_request_handling
Type: STRUCT
Provider name: CustomRequestHandling
Description: Defines custom handling for the web request. For information about customizing web requests and responses, see Customizing web requests and responses in WAF in the WAF Developer Guide.
insert_headers
Type: UNORDERED_LIST_STRUCT
Provider name: InsertHeaders
Description: The HTTP headers to insert into the request. Duplicate header names are not allowed. For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
name
Type: STRING
Provider name: Name
Description: The name of the custom header. For custom request header insertion, when WAF inserts the header into the request, it prefixes this name x-amzn-waf-
, to avoid confusion with the headers that are already in the request. For example, for the header name sample
, WAF inserts the header x-amzn-waf-sample
.
value
Type: STRING
Provider name: Value
Description: The value of the custom header.
name
Type: STRING
Provider name: Name
Description: The name of the rule to override.
size_constraint_statement
Type: STRUCT
Provider name: SizeConstraintStatement
Description: A rule statement that compares a number of bytes against the size of a request component, using a comparison operator, such as greater than (>) or less than (<). For example, you can use a size constraint statement to look for query strings that are longer than 100 bytes. If you configure WAF to inspect the request body, WAF inspects only the number of bytes in the body up to the limit for the web ACL and protected resource type. If you know that the request body for your web requests should never exceed the inspection limit, you can use a size constraint statement to block requests that have a larger request body size. For more information about the inspection limits, see Body
and JsonBody
settings for the FieldToMatch
data type. If you choose URI for the value of Part of the request to filter on, the slash (/) in the URI counts as one character. For example, the URI /logo.jpg
is nine characters long.
comparison_operator
Type: STRING
Provider name: ComparisonOperator
Description: The operator to use to compare the request part to the size setting.
field_to_match
Type: STRUCT
Provider name: FieldToMatch
Description: The part of the web request that you want WAF to inspect.
all_query_arguments
Type: STRUCT
Provider name: AllQueryArguments
Description: Inspect all query arguments.
body
Type: STRUCT
Provider name: Body
Description: Inspect the request body as plain text. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the Body
object configuration.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
cookies
Type: STRUCT
Provider name: Cookies
Description: Inspect the request cookies. You must configure scope and pattern matching filters in the Cookies
object, to define the set of cookies and the parts of the cookies that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s cookies and only the first 200 cookies are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize cookie content in the Cookies
object. WAF applies the pattern matching filters to the cookies that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of cookies to inspect in a web request. You must specify exactly one setting: either All
, IncludedCookies
, or ExcludedCookies
. Example JSON: “MatchPattern”: { “IncludedCookies”: [ “session-id-time”, “session-id” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all cookies.
excluded_cookies
Type: UNORDERED_LIST_STRING
Provider name: ExcludedCookies
Description: Inspect only the cookies whose keys don’t match any of the strings specified here.
included_cookies
Type: UNORDERED_LIST_STRING
Provider name: IncludedCookies
Description: Inspect only the cookies that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the cookies to inspect with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the cookies of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request cookies when they exceed 8 KB (8192 bytes) or 200 total cookies. The underlying host service forwards a maximum of 200 cookies and at most 8 KB of cookie contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available cookies normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
header_order
Type: STRUCT
Provider name: HeaderOrder
Description: Inspect a string containing the list of the request’s header names, ordered as they appear in the web request that WAF receives for inspection. WAF generates the string and then uses that as the field to match component in its inspection. WAF separates the header names in the string using colons and no added spaces, for example host:user-agent:accept:authorization:referer
.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
headers
Type: STRUCT
Provider name: Headers
Description: Inspect the request headers. You must configure scope and pattern matching filters in the Headers
object, to define the set of headers to and the parts of the headers that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s headers and only the first 200 headers are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize header content in the Headers
object. WAF applies the pattern matching filters to the headers that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of headers to inspect in a web request. You must specify exactly one setting: either All
, IncludedHeaders
, or ExcludedHeaders
. Example JSON: “MatchPattern”: { “ExcludedHeaders”: [ “KeyToExclude1”, “KeyToExclude2” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all headers.
excluded_headers
Type: UNORDERED_LIST_STRING
Provider name: ExcludedHeaders
Description: Inspect only the headers whose keys don’t match any of the strings specified here.
included_headers
Type: UNORDERED_LIST_STRING
Provider name: IncludedHeaders
Description: Inspect only the headers that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the headers to match with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
ja3_fingerprint
Type: STRUCT
Provider name: JA3Fingerprint
Description: Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request’s JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client’s TLS configuration. WAF calculates and logs this fingerprint for each request that has enough TLS Client Hello information for the calculation. Almost all web requests include this information. You can use this choice only with a string match ByteMatchStatement
with the PositionalConstraint
set to EXACTLY
. You can obtain the JA3 fingerprint for client requests from the web ACL logs. If WAF is able to calculate the fingerprint, it includes it in the logs. For information about the logging fields, see Log fields in the WAF Developer Guide. Provide the JA3 fingerprint string from the logs in your string match statement specification, to match with any future requests that have the same TLS configuration.
fallback_behavior
Type: STRING
Provider name: FallbackBehavior
Description: The match status to assign to the web request if the request doesn’t have a JA3 fingerprint. You can specify the following fallback behaviors:MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
json_body
Type: STRUCT
Provider name: JsonBody
Description: Inspect the request body as JSON. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the JsonBody
object configuration.
invalid_fallback_behavior
Type: STRING
Provider name: InvalidFallbackBehavior
Description: What WAF should do if it fails to completely parse the JSON body. The options are the following:EVALUATE_AS_STRING
- Inspect the body as plain text. WAF applies the text transformations and inspection criteria that you defined for the JSON inspection to the body text string.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
If you don’t provide this setting, WAF parses and evaluates the content only up to the first parsing failure that it encounters. WAF parsing doesn’t fully validate the input JSON string, so parsing can succeed even for invalid JSON. When parsing succeeds, WAF doesn’t apply the fallback behavior. For more information, see JSON body in the WAF Developer Guide.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
all
Type: STRUCT
Provider name: All
Description: Match all of the elements. See also MatchScope
in JsonBody. You must specify either this setting or the IncludedPaths
setting, but not both.
included_paths
Type: UNORDERED_LIST_STRING
Provider name: IncludedPaths
Description: Match only the specified include paths. See also MatchScope
in JsonBody. Provide the include paths using JSON Pointer syntax. For example, “IncludedPaths”: ["/dogs/0/name", “/dogs/1/name”]
. For information about this syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. You must specify either this setting or the All
setting, but not both. Don’t use this option to include all paths. Instead, use the All
setting.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the JSON to match against using the MatchPattern
. If you specify ALL
, WAF matches against keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
method
Type: STRUCT
Provider name: Method
Description: Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
query_string
Type: STRUCT
Provider name: QueryString
Description: Inspect the query string. This is the part of a URL that appears after a ?
character, if any.
single_header
Type: STRUCT
Provider name: SingleHeader
Description: Inspect a single header. Provide the name of the header to inspect, for example, User-Agent
or Referer
. This setting isn’t case sensitive. Example JSON: “SingleHeader”: { “Name”: “haystack” }
Alternately, you can filter and inspect all headers with the Headers
FieldToMatch
setting.
name
Type: STRING
Provider name: Name
Description: The name of the query header to inspect.
single_query_argument
Type: STRUCT
Provider name: SingleQueryArgument
Description: Inspect a single query argument. Provide the name of the query argument to inspect, such as UserName or SalesRegion. The name can be up to 30 characters long and isn’t case sensitive. Example JSON: “SingleQueryArgument”: { “Name”: “myArgument” }
name
Type: STRING
Provider name: Name
Description: The name of the query argument to inspect.
uri_path
Type: STRUCT
Provider name: UriPath
Description: Inspect the request URI path. This is the part of the web request that identifies a resource, for example, /images/daily-ad.jpg
.
size
Type: INT64
Provider name: Size
Description: The size, in byte, to compare to the request part, after any transformations.
text_transformations
Type: UNORDERED_LIST_STRUCT
Provider name: TextTransformations
Description: Text transformations eliminate some of the unusual formatting that attackers use in web requests in an effort to bypass detection. Text transformations are used in rule match statements, to transform the FieldToMatch
request component before inspecting it, and they’re used in rate-based rule statements, to transform request components before using them as custom aggregation keys. If you specify one or more transformations to apply, WAF performs all transformations on the specified content, starting from the lowest priority setting, and then uses the transformed component contents.
priority
Type: INT32
Provider name: Priority
Description: Sets the relative processing order for multiple transformations. WAF processes all transformations, from lowest priority to highest, before inspecting the transformed content. The priorities don’t need to be consecutive, but they must all be different.
type
Type: STRING
Provider name: Type
Description: For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
sqli_match_statement
Type: STRUCT
Provider name: SqliMatchStatement
Description: A rule statement that inspects for malicious SQL code. Attackers insert malicious SQL code into web requests to do things like modify your database or extract data from it.
field_to_match
Type: STRUCT
Provider name: FieldToMatch
Description: The part of the web request that you want WAF to inspect.
all_query_arguments
Type: STRUCT
Provider name: AllQueryArguments
Description: Inspect all query arguments.
body
Type: STRUCT
Provider name: Body
Description: Inspect the request body as plain text. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the Body
object configuration.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
cookies
Type: STRUCT
Provider name: Cookies
Description: Inspect the request cookies. You must configure scope and pattern matching filters in the Cookies
object, to define the set of cookies and the parts of the cookies that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s cookies and only the first 200 cookies are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize cookie content in the Cookies
object. WAF applies the pattern matching filters to the cookies that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of cookies to inspect in a web request. You must specify exactly one setting: either All
, IncludedCookies
, or ExcludedCookies
. Example JSON: “MatchPattern”: { “IncludedCookies”: [ “session-id-time”, “session-id” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all cookies.
excluded_cookies
Type: UNORDERED_LIST_STRING
Provider name: ExcludedCookies
Description: Inspect only the cookies whose keys don’t match any of the strings specified here.
included_cookies
Type: UNORDERED_LIST_STRING
Provider name: IncludedCookies
Description: Inspect only the cookies that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the cookies to inspect with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the cookies of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request cookies when they exceed 8 KB (8192 bytes) or 200 total cookies. The underlying host service forwards a maximum of 200 cookies and at most 8 KB of cookie contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available cookies normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
header_order
Type: STRUCT
Provider name: HeaderOrder
Description: Inspect a string containing the list of the request’s header names, ordered as they appear in the web request that WAF receives for inspection. WAF generates the string and then uses that as the field to match component in its inspection. WAF separates the header names in the string using colons and no added spaces, for example host:user-agent:accept:authorization:referer
.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
headers
Type: STRUCT
Provider name: Headers
Description: Inspect the request headers. You must configure scope and pattern matching filters in the Headers
object, to define the set of headers to and the parts of the headers that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s headers and only the first 200 headers are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize header content in the Headers
object. WAF applies the pattern matching filters to the headers that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of headers to inspect in a web request. You must specify exactly one setting: either All
, IncludedHeaders
, or ExcludedHeaders
. Example JSON: “MatchPattern”: { “ExcludedHeaders”: [ “KeyToExclude1”, “KeyToExclude2” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all headers.
excluded_headers
Type: UNORDERED_LIST_STRING
Provider name: ExcludedHeaders
Description: Inspect only the headers whose keys don’t match any of the strings specified here.
included_headers
Type: UNORDERED_LIST_STRING
Provider name: IncludedHeaders
Description: Inspect only the headers that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the headers to match with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
ja3_fingerprint
Type: STRUCT
Provider name: JA3Fingerprint
Description: Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request’s JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client’s TLS configuration. WAF calculates and logs this fingerprint for each request that has enough TLS Client Hello information for the calculation. Almost all web requests include this information. You can use this choice only with a string match ByteMatchStatement
with the PositionalConstraint
set to EXACTLY
. You can obtain the JA3 fingerprint for client requests from the web ACL logs. If WAF is able to calculate the fingerprint, it includes it in the logs. For information about the logging fields, see Log fields in the WAF Developer Guide. Provide the JA3 fingerprint string from the logs in your string match statement specification, to match with any future requests that have the same TLS configuration.
fallback_behavior
Type: STRING
Provider name: FallbackBehavior
Description: The match status to assign to the web request if the request doesn’t have a JA3 fingerprint. You can specify the following fallback behaviors:MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
json_body
Type: STRUCT
Provider name: JsonBody
Description: Inspect the request body as JSON. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the JsonBody
object configuration.
invalid_fallback_behavior
Type: STRING
Provider name: InvalidFallbackBehavior
Description: What WAF should do if it fails to completely parse the JSON body. The options are the following:EVALUATE_AS_STRING
- Inspect the body as plain text. WAF applies the text transformations and inspection criteria that you defined for the JSON inspection to the body text string.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
If you don’t provide this setting, WAF parses and evaluates the content only up to the first parsing failure that it encounters. WAF parsing doesn’t fully validate the input JSON string, so parsing can succeed even for invalid JSON. When parsing succeeds, WAF doesn’t apply the fallback behavior. For more information, see JSON body in the WAF Developer Guide.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
all
Type: STRUCT
Provider name: All
Description: Match all of the elements. See also MatchScope
in JsonBody. You must specify either this setting or the IncludedPaths
setting, but not both.
included_paths
Type: UNORDERED_LIST_STRING
Provider name: IncludedPaths
Description: Match only the specified include paths. See also MatchScope
in JsonBody. Provide the include paths using JSON Pointer syntax. For example, “IncludedPaths”: ["/dogs/0/name", “/dogs/1/name”]
. For information about this syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. You must specify either this setting or the All
setting, but not both. Don’t use this option to include all paths. Instead, use the All
setting.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the JSON to match against using the MatchPattern
. If you specify ALL
, WAF matches against keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
method
Type: STRUCT
Provider name: Method
Description: Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
query_string
Type: STRUCT
Provider name: QueryString
Description: Inspect the query string. This is the part of a URL that appears after a ?
character, if any.
single_header
Type: STRUCT
Provider name: SingleHeader
Description: Inspect a single header. Provide the name of the header to inspect, for example, User-Agent
or Referer
. This setting isn’t case sensitive. Example JSON: “SingleHeader”: { “Name”: “haystack” }
Alternately, you can filter and inspect all headers with the Headers
FieldToMatch
setting.
name
Type: STRING
Provider name: Name
Description: The name of the query header to inspect.
single_query_argument
Type: STRUCT
Provider name: SingleQueryArgument
Description: Inspect a single query argument. Provide the name of the query argument to inspect, such as UserName or SalesRegion. The name can be up to 30 characters long and isn’t case sensitive. Example JSON: “SingleQueryArgument”: { “Name”: “myArgument” }
name
Type: STRING
Provider name: Name
Description: The name of the query argument to inspect.
uri_path
Type: STRUCT
Provider name: UriPath
Description: Inspect the request URI path. This is the part of the web request that identifies a resource, for example, /images/daily-ad.jpg
.
sensitivity_level
Type: STRING
Provider name: SensitivityLevel
Description: The sensitivity that you want WAF to use to inspect for SQL injection attacks. HIGH
detects more attacks, but might generate more false positives, especially if your web requests frequently contain unusual strings. For information about identifying and mitigating false positives, see Testing and tuning in the WAF Developer Guide. LOW
is generally a better choice for resources that already have other protections against SQL injection attacks or that have a low tolerance for false positives.
Default: LOW
text_transformations
Type: UNORDERED_LIST_STRUCT
Provider name: TextTransformations
Description: Text transformations eliminate some of the unusual formatting that attackers use in web requests in an effort to bypass detection. Text transformations are used in rule match statements, to transform the FieldToMatch
request component before inspecting it, and they’re used in rate-based rule statements, to transform request components before using them as custom aggregation keys. If you specify one or more transformations to apply, WAF performs all transformations on the specified content, starting from the lowest priority setting, and then uses the transformed component contents.
priority
Type: INT32
Provider name: Priority
Description: Sets the relative processing order for multiple transformations. WAF processes all transformations, from lowest priority to highest, before inspecting the transformed content. The priorities don’t need to be consecutive, but they must all be different.
type
Type: STRING
Provider name: Type
Description: For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
xss_match_statement
Type: STRUCT
Provider name: XssMatchStatement
Description: A rule statement that inspects for cross-site scripting (XSS) attacks. In XSS attacks, the attacker uses vulnerabilities in a benign website as a vehicle to inject malicious client-site scripts into other legitimate web browsers.
field_to_match
Type: STRUCT
Provider name: FieldToMatch
Description: The part of the web request that you want WAF to inspect.
all_query_arguments
Type: STRUCT
Provider name: AllQueryArguments
Description: Inspect all query arguments.
body
Type: STRUCT
Provider name: Body
Description: Inspect the request body as plain text. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the Body
object configuration.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
cookies
Type: STRUCT
Provider name: Cookies
Description: Inspect the request cookies. You must configure scope and pattern matching filters in the Cookies
object, to define the set of cookies and the parts of the cookies that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s cookies and only the first 200 cookies are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize cookie content in the Cookies
object. WAF applies the pattern matching filters to the cookies that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of cookies to inspect in a web request. You must specify exactly one setting: either All
, IncludedCookies
, or ExcludedCookies
. Example JSON: “MatchPattern”: { “IncludedCookies”: [ “session-id-time”, “session-id” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all cookies.
excluded_cookies
Type: UNORDERED_LIST_STRING
Provider name: ExcludedCookies
Description: Inspect only the cookies whose keys don’t match any of the strings specified here.
included_cookies
Type: UNORDERED_LIST_STRING
Provider name: IncludedCookies
Description: Inspect only the cookies that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the cookies to inspect with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the cookies of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request cookies when they exceed 8 KB (8192 bytes) or 200 total cookies. The underlying host service forwards a maximum of 200 cookies and at most 8 KB of cookie contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available cookies normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
header_order
Type: STRUCT
Provider name: HeaderOrder
Description: Inspect a string containing the list of the request’s header names, ordered as they appear in the web request that WAF receives for inspection. WAF generates the string and then uses that as the field to match component in its inspection. WAF separates the header names in the string using colons and no added spaces, for example host:user-agent:accept:authorization:referer
.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
headers
Type: STRUCT
Provider name: Headers
Description: Inspect the request headers. You must configure scope and pattern matching filters in the Headers
object, to define the set of headers to and the parts of the headers that WAF inspects. Only the first 8 KB (8192 bytes) of a request’s headers and only the first 200 headers are forwarded to WAF for inspection by the underlying host service. You must configure how to handle any oversize header content in the Headers
object. WAF applies the pattern matching filters to the headers that it receives from the underlying host service.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The filter to use to identify the subset of headers to inspect in a web request. You must specify exactly one setting: either All
, IncludedHeaders
, or ExcludedHeaders
. Example JSON: “MatchPattern”: { “ExcludedHeaders”: [ “KeyToExclude1”, “KeyToExclude2” ] }
all
Type: STRUCT
Provider name: All
Description: Inspect all headers.
excluded_headers
Type: UNORDERED_LIST_STRING
Provider name: ExcludedHeaders
Description: Inspect only the headers whose keys don’t match any of the strings specified here.
included_headers
Type: UNORDERED_LIST_STRING
Provider name: IncludedHeaders
Description: Inspect only the headers that have a key that matches one of the strings specified here.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the headers to match with the rule inspection criteria. If you specify ALL
, WAF inspects both keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the headers of the request are more numerous or larger than WAF can inspect. WAF does not support inspecting the entire contents of request headers when they exceed 8 KB (8192 bytes) or 200 total headers. The underlying host service forwards a maximum of 200 headers and at most 8 KB of header contents to WAF. The options for oversize handling are the following:CONTINUE
- Inspect the available headers normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
ja3_fingerprint
Type: STRUCT
Provider name: JA3Fingerprint
Description: Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request’s JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client’s TLS configuration. WAF calculates and logs this fingerprint for each request that has enough TLS Client Hello information for the calculation. Almost all web requests include this information. You can use this choice only with a string match ByteMatchStatement
with the PositionalConstraint
set to EXACTLY
. You can obtain the JA3 fingerprint for client requests from the web ACL logs. If WAF is able to calculate the fingerprint, it includes it in the logs. For information about the logging fields, see Log fields in the WAF Developer Guide. Provide the JA3 fingerprint string from the logs in your string match statement specification, to match with any future requests that have the same TLS configuration.
fallback_behavior
Type: STRING
Provider name: FallbackBehavior
Description: The match status to assign to the web request if the request doesn’t have a JA3 fingerprint. You can specify the following fallback behaviors:MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
json_body
Type: STRUCT
Provider name: JsonBody
Description: Inspect the request body as JSON. The request body immediately follows the request headers. This is the part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.
- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
For information about how to handle oversized request bodies, see the JsonBody
object configuration.
invalid_fallback_behavior
Type: STRING
Provider name: InvalidFallbackBehavior
Description: What WAF should do if it fails to completely parse the JSON body. The options are the following:EVALUATE_AS_STRING
- Inspect the body as plain text. WAF applies the text transformations and inspection criteria that you defined for the JSON inspection to the body text string.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
If you don’t provide this setting, WAF parses and evaluates the content only up to the first parsing failure that it encounters. WAF parsing doesn’t fully validate the input JSON string, so parsing can succeed even for invalid JSON. When parsing succeeds, WAF doesn’t apply the fallback behavior. For more information, see JSON body in the WAF Developer Guide.
match_pattern
Type: STRUCT
Provider name: MatchPattern
Description: The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
all
Type: STRUCT
Provider name: All
Description: Match all of the elements. See also MatchScope
in JsonBody. You must specify either this setting or the IncludedPaths
setting, but not both.
included_paths
Type: UNORDERED_LIST_STRING
Provider name: IncludedPaths
Description: Match only the specified include paths. See also MatchScope
in JsonBody. Provide the include paths using JSON Pointer syntax. For example, “IncludedPaths”: ["/dogs/0/name", “/dogs/1/name”]
. For information about this syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer. You must specify either this setting or the All
setting, but not both. Don’t use this option to include all paths. Instead, use the All
setting.
match_scope
Type: STRING
Provider name: MatchScope
Description: The parts of the JSON to match against using the MatchPattern
. If you specify ALL
, WAF matches against keys and values. All
does not require a match to be found in the keys and a match to be found in the values. It requires a match to be found in the keys or the values or both. To require a match in the keys and in the values, use a logical AND
statement to combine two match rules, one that inspects the keys and another that inspects the values.
oversize_handling
Type: STRING
Provider name: OversizeHandling
Description: What WAF should do if the body is larger than WAF can inspect. WAF does not support inspecting the entire contents of the web request body if the body exceeds the limit for the resource type. When a web request body is larger than the limit, the underlying host service only forwards the contents that are within the limit to WAF for inspection.- For Application Load Balancer and AppSync, the limit is fixed at 8 KB (8,192 bytes).
- For CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access, the default limit is 16 KB (16,384 bytes), and you can increase the limit for each resource type in the web ACL
AssociationConfig
, for additional processing fees.
The options for oversize handling are the following:CONTINUE
- Inspect the available body contents normally, according to the rule inspection criteria.MATCH
- Treat the web request as matching the rule statement. WAF applies the rule action to the request.NO_MATCH
- Treat the web request as not matching the rule statement.
You can combine the MATCH
or NO_MATCH
settings for oversize handling with your rule and web ACL action settings, so that you block any request whose body is over the limit.
Default: CONTINUE
method
Type: STRUCT
Provider name: Method
Description: Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
query_string
Type: STRUCT
Provider name: QueryString
Description: Inspect the query string. This is the part of a URL that appears after a ?
character, if any.
single_header
Type: STRUCT
Provider name: SingleHeader
Description: Inspect a single header. Provide the name of the header to inspect, for example, User-Agent
or Referer
. This setting isn’t case sensitive. Example JSON: “SingleHeader”: { “Name”: “haystack” }
Alternately, you can filter and inspect all headers with the Headers
FieldToMatch
setting.
name
Type: STRING
Provider name: Name
Description: The name of the query header to inspect.
single_query_argument
Type: STRUCT
Provider name: SingleQueryArgument
Description: Inspect a single query argument. Provide the name of the query argument to inspect, such as UserName or SalesRegion. The name can be up to 30 characters long and isn’t case sensitive. Example JSON: “SingleQueryArgument”: { “Name”: “myArgument” }
name
Type: STRING
Provider name: Name
Description: The name of the query argument to inspect.
uri_path
Type: STRUCT
Provider name: UriPath
Description: Inspect the request URI path. This is the part of the web request that identifies a resource, for example, /images/daily-ad.jpg
.
text_transformations
Type: UNORDERED_LIST_STRUCT
Provider name: TextTransformations
Description: Text transformations eliminate some of the unusual formatting that attackers use in web requests in an effort to bypass detection. Text transformations are used in rule match statements, to transform the FieldToMatch
request component before inspecting it, and they’re used in rate-based rule statements, to transform request components before using them as custom aggregation keys. If you specify one or more transformations to apply, WAF performs all transformations on the specified content, starting from the lowest priority setting, and then uses the transformed component contents.
priority
Type: INT32
Provider name: Priority
Description: Sets the relative processing order for multiple transformations. WAF processes all transformations, from lowest priority to highest, before inspecting the transformed content. The priorities don’t need to be consecutive, but they must all be different.
type
Type: STRING
Provider name: Type
Description: For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
visibility_config
Type: STRUCT
Provider name: VisibilityConfig
Description: Defines and enables Amazon CloudWatch metrics and web request sample collection. If you change the name of a Rule
after you create it and you want the rule’s metric name to reflect the change, update the metric name as well. WAF doesn’t automatically update the metric name.
cloud_watch_metrics_enabled
Type: BOOLEAN
Provider name: CloudWatchMetricsEnabled
Description: Indicates whether the associated resource sends metrics to Amazon CloudWatch. For the list of available metrics, see WAF Metrics in the WAF Developer Guide. For web ACLs, the metrics are for web requests that have the web ACL default action applied. WAF applies the default action to web requests that pass the inspection of all rules in the web ACL without being either allowed or blocked. For more information, see The web ACL default action in the WAF Developer Guide.
metric_name
Type: STRING
Provider name: MetricName
Description: A name of the Amazon CloudWatch metric dimension. The name can contain only the characters: A-Z, a-z, 0-9, - (hyphen), and _ (underscore). The name can be from one to 128 characters long. It can’t contain whitespace or metric names that are reserved for WAF, for example All
and Default_Action
.
sampled_requests_enabled
Type: BOOLEAN
Provider name: SampledRequestsEnabled
Description: Indicates whether WAF should store a sampling of the web requests that match the rules. You can view the sampled requests through the WAF console. Request sampling doesn’t provide a field redaction option, and any field redaction that you specify in your logging configuration doesn’t affect sampling. The only way to exclude fields from request sampling is by disabling sampling in the web ACL visibility configuration.
token_domains
Type: UNORDERED_LIST_STRING
Provider name: TokenDomains
Description: Specifies the domains that WAF should accept in a web request token. This enables the use of tokens across multiple protected websites. When WAF provides a token, it uses the domain of the Amazon Web Services resource that the web ACL is protecting. If you don’t specify a list of token domains, WAF accepts tokens only for the domain of the protected resource. With a token domain list, WAF accepts the resource’s host domain plus all domains in the token domain list, including their prefixed subdomains.
visibility_config
Type: STRUCT
Provider name: VisibilityConfig
Description: Defines and enables Amazon CloudWatch metrics and web request sample collection.
cloud_watch_metrics_enabled
Type: BOOLEAN
Provider name: CloudWatchMetricsEnabled
Description: Indicates whether the associated resource sends metrics to Amazon CloudWatch. For the list of available metrics, see WAF Metrics in the WAF Developer Guide. For web ACLs, the metrics are for web requests that have the web ACL default action applied. WAF applies the default action to web requests that pass the inspection of all rules in the web ACL without being either allowed or blocked. For more information, see The web ACL default action in the WAF Developer Guide.
metric_name
Type: STRING
Provider name: MetricName
Description: A name of the Amazon CloudWatch metric dimension. The name can contain only the characters: A-Z, a-z, 0-9, - (hyphen), and _ (underscore). The name can be from one to 128 characters long. It can’t contain whitespace or metric names that are reserved for WAF, for example All
and Default_Action
.
sampled_requests_enabled
Type: BOOLEAN
Provider name: SampledRequestsEnabled
Description: Indicates whether WAF should store a sampling of the web requests that match the rules. You can view the sampled requests through the WAF console. Request sampling doesn’t provide a field redaction option, and any field redaction that you specify in your logging configuration doesn’t affect sampling. The only way to exclude fields from request sampling is by disabling sampling in the web ACL visibility configuration.