Class: AWS.WAFV2
- Inherits:
-
AWS.Service
- Object
- AWS.Service
- AWS.WAFV2
- Identifier:
- wafv2
- API Version:
- 2019-07-29
- Defined in:
- (unknown)
Overview
Constructs a service interface object. Each API operation is exposed as a function on service.
Service Description
WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to an Amazon CloudFront distribution, Amazon API Gateway REST API, Application Load Balancer, AppSync GraphQL API, Amazon Cognito user pool, App Runner service, or Amazon Web Services Verified Access instance. WAF also lets you control access to your content, to protect the Amazon Web Services resource that WAF is monitoring. Based on conditions that you specify, such as the IP addresses that requests originate from or the values of query strings, the protected resource responds to requests with either the requested content, an HTTP 403 status code (Forbidden), or with a custom response.
This API guide is for developers who need detailed information about WAF API actions, data types, and errors. For detailed information about WAF features and guidance for configuring and using WAF, see the WAF Developer Guide.
You can make calls using the endpoints listed in WAF endpoints and quotas.
-
For regional applications, you can use any of the endpoints in the list. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
-
For Amazon CloudFront applications, you must use the API endpoint listed for US East (N. Virginia): us-east-1.
Alternatively, you can use one of the Amazon Web Services SDKs to access an API that's tailored to the programming language or platform that you're using. For more information, see Amazon Web Services SDKs.
We currently provide two versions of the WAF API: this API and the prior versions, the classic WAF APIs. This new API provides the same functionality as the older versions, with the following major improvements:
-
You use one API for both global and regional applications. Where you need to distinguish the scope, you specify a
Scope
parameter and set it toCLOUDFRONT
orREGIONAL
. -
You can define a web ACL or rule group with a single call, and update it with a single call. You define all rule specifications in JSON format, and pass them to your rule group or web ACL calls.
-
The limits WAF places on the use of rules more closely reflects the cost of running each type of rule. Rule groups include capacity settings, so you know the maximum cost of a rule group when you use it.
Sending a Request Using WAFV2
var wafv2 = new AWS.WAFV2();
wafv2.associateWebACL(params, function (err, data) {
if (err) console.log(err, err.stack); // an error occurred
else console.log(data); // successful response
});
Locking the API Version
In order to ensure that the WAFV2 object uses this specific API, you can
construct the object by passing the apiVersion
option to the constructor:
var wafv2 = new AWS.WAFV2({apiVersion: '2019-07-29'});
You can also set the API version globally in AWS.config.apiVersions
using
the wafv2 service identifier:
AWS.config.apiVersions = {
wafv2: '2019-07-29',
// other service API versions
};
var wafv2 = new AWS.WAFV2();
Version:
-
2019-07-29
Constructor Summary collapse
-
new AWS.WAFV2(options = {}) ⇒ Object
constructor
Constructs a service object.
Property Summary collapse
-
endpoint ⇒ AWS.Endpoint
readwrite
An Endpoint object representing the endpoint URL for service requests.
Properties inherited from AWS.Service
Method Summary collapse
-
associateWebACL(params = {}, callback) ⇒ AWS.Request
Associates a web ACL with a regional application resource, to protect the resource.
-
checkCapacity(params = {}, callback) ⇒ AWS.Request
Returns the web ACL capacity unit (WCU) requirements for a specified scope and set of rules.
-
createAPIKey(params = {}, callback) ⇒ AWS.Request
Creates an API key that contains a set of token domains.
API keys are required for the integration of the CAPTCHA API in your JavaScript client applications.
-
createIPSet(params = {}, callback) ⇒ AWS.Request
Creates an IPSet, which you use to identify web requests that originate from specific IP addresses or ranges of IP addresses.
-
createRegexPatternSet(params = {}, callback) ⇒ AWS.Request
Creates a RegexPatternSet, which you reference in a RegexPatternSetReferenceStatement, to have WAF inspect a web request component for the specified patterns.
.
-
createRuleGroup(params = {}, callback) ⇒ AWS.Request
Creates a RuleGroup per the specifications provided.
-
createWebACL(params = {}, callback) ⇒ AWS.Request
Creates a WebACL per the specifications provided.
A web ACL defines a collection of rules to use to inspect and control web requests.
-
deleteAPIKey(params = {}, callback) ⇒ AWS.Request
Deletes the specified API key.
-
deleteFirewallManagerRuleGroups(params = {}, callback) ⇒ AWS.Request
Deletes all rule groups that are managed by Firewall Manager for the specified web ACL.
-
deleteIPSet(params = {}, callback) ⇒ AWS.Request
Deletes the specified IPSet.
-
deleteLoggingConfiguration(params = {}, callback) ⇒ AWS.Request
Deletes the LoggingConfiguration from the specified web ACL.
.
-
deletePermissionPolicy(params = {}, callback) ⇒ AWS.Request
Permanently deletes an IAM policy from the specified rule group.
You must be the owner of the rule group to perform this operation.
. -
deleteRegexPatternSet(params = {}, callback) ⇒ AWS.Request
Deletes the specified RegexPatternSet.
.
-
deleteRuleGroup(params = {}, callback) ⇒ AWS.Request
Deletes the specified RuleGroup.
.
-
deleteWebACL(params = {}, callback) ⇒ AWS.Request
Deletes the specified WebACL.
-
describeAllManagedProducts(params = {}, callback) ⇒ AWS.Request
Provides high-level information for the Amazon Web Services Managed Rules rule groups and Amazon Web Services Marketplace managed rule groups.
-
describeManagedProductsByVendor(params = {}, callback) ⇒ AWS.Request
Provides high-level information for the managed rule groups owned by a specific vendor.
-
describeManagedRuleGroup(params = {}, callback) ⇒ AWS.Request
Provides high-level information for a managed rule group, including descriptions of the rules.
-
disassociateWebACL(params = {}, callback) ⇒ AWS.Request
Disassociates the specified regional application resource from any existing web ACL association.
-
generateMobileSdkReleaseUrl(params = {}, callback) ⇒ AWS.Request
Generates a presigned download URL for the specified release of the mobile SDK.
The mobile SDK is not generally available.
-
getDecryptedAPIKey(params = {}, callback) ⇒ AWS.Request
Returns your API key in decrypted form.
-
getIPSet(params = {}, callback) ⇒ AWS.Request
Retrieves the specified IPSet.
.
-
getLoggingConfiguration(params = {}, callback) ⇒ AWS.Request
Returns the LoggingConfiguration for the specified web ACL.
.
-
getManagedRuleSet(params = {}, callback) ⇒ AWS.Request
Retrieves the specified managed rule set.
-
getMobileSdkRelease(params = {}, callback) ⇒ AWS.Request
Retrieves information for the specified mobile SDK release, including release notes and tags.
The mobile SDK is not generally available.
-
getPermissionPolicy(params = {}, callback) ⇒ AWS.Request
Returns the IAM policy that is attached to the specified rule group.
You must be the owner of the rule group to perform this operation.
. -
getRateBasedStatementManagedKeys(params = {}, callback) ⇒ AWS.Request
Retrieves the IP addresses that are currently blocked by a rate-based rule instance.
-
getRegexPatternSet(params = {}, callback) ⇒ AWS.Request
Retrieves the specified RegexPatternSet.
.
-
getRuleGroup(params = {}, callback) ⇒ AWS.Request
Retrieves the specified RuleGroup.
.
-
getSampledRequests(params = {}, callback) ⇒ AWS.Request
Gets detailed information about a specified number of requests--a sample--that WAF randomly selects from among the first 5,000 requests that your Amazon Web Services resource received during a time range that you choose.
-
getWebACL(params = {}, callback) ⇒ AWS.Request
Retrieves the specified WebACL.
.
-
getWebACLForResource(params = {}, callback) ⇒ AWS.Request
Retrieves the WebACL for the specified resource.
-
listAPIKeys(params = {}, callback) ⇒ AWS.Request
Retrieves a list of the API keys that you've defined for the specified scope.
-
listAvailableManagedRuleGroups(params = {}, callback) ⇒ AWS.Request
Retrieves an array of managed rule groups that are available for you to use.
-
listAvailableManagedRuleGroupVersions(params = {}, callback) ⇒ AWS.Request
Returns a list of the available versions for the specified managed rule group.
-
listIPSets(params = {}, callback) ⇒ AWS.Request
Retrieves an array of IPSetSummary objects for the IP sets that you manage.
.
-
listLoggingConfigurations(params = {}, callback) ⇒ AWS.Request
Retrieves an array of your LoggingConfiguration objects.
.
-
listManagedRuleSets(params = {}, callback) ⇒ AWS.Request
Retrieves the managed rule sets that you own.
-
listMobileSdkReleases(params = {}, callback) ⇒ AWS.Request
Retrieves a list of the available releases for the mobile SDK and the specified device platform.
-
listRegexPatternSets(params = {}, callback) ⇒ AWS.Request
Retrieves an array of RegexPatternSetSummary objects for the regex pattern sets that you manage.
.
-
listResourcesForWebACL(params = {}, callback) ⇒ AWS.Request
Retrieves an array of the Amazon Resource Names (ARNs) for the regional resources that are associated with the specified web ACL.
-
listRuleGroups(params = {}, callback) ⇒ AWS.Request
Retrieves an array of RuleGroupSummary objects for the rule groups that you manage.
-
listTagsForResource(params = {}, callback) ⇒ AWS.Request
Retrieves the TagInfoForResource for the specified resource.
-
listWebACLs(params = {}, callback) ⇒ AWS.Request
Retrieves an array of WebACLSummary objects for the web ACLs that you manage.
.
-
putLoggingConfiguration(params = {}, callback) ⇒ AWS.Request
Enables the specified LoggingConfiguration, to start logging from a web ACL, according to the configuration provided.
-
putManagedRuleSetVersions(params = {}, callback) ⇒ AWS.Request
Defines the versions of your managed rule set that you are offering to the customers.
-
putPermissionPolicy(params = {}, callback) ⇒ AWS.Request
Use this to share a rule group with other accounts.
This action attaches an IAM policy to the specified resource.
-
tagResource(params = {}, callback) ⇒ AWS.Request
Associates tags with the specified Amazon Web Services resource.
-
untagResource(params = {}, callback) ⇒ AWS.Request
Disassociates tags from an Amazon Web Services resource.
-
updateIPSet(params = {}, callback) ⇒ AWS.Request
Updates the specified IPSet.
-
updateManagedRuleSetVersionExpiryDate(params = {}, callback) ⇒ AWS.Request
Updates the expiration information for your managed rule set.
-
updateRegexPatternSet(params = {}, callback) ⇒ AWS.Request
Updates the specified RegexPatternSet.
Note: This operation completely replaces the mutable specifications that you already have for the regex pattern set with the ones that you provide to this call.- updateRuleGroup(params = {}, callback) ⇒ AWS.Request
Updates the specified RuleGroup.
Note: This operation completely replaces the mutable specifications that you already have for the rule group with the ones that you provide to this call.- updateWebACL(params = {}, callback) ⇒ AWS.Request
Updates the specified WebACL.
Methods inherited from AWS.Service
makeRequest, makeUnauthenticatedRequest, waitFor, setupRequestListeners, defineService
Constructor Details
new AWS.WAFV2(options = {}) ⇒ Object
Constructs a service object. This object has one method for each API operation.
Examples:
Constructing a WAFV2 object
var wafv2 = new AWS.WAFV2({apiVersion: '2019-07-29'});
Options Hash (options):
-
params
(map)
—
An optional map of parameters to bind to every request sent by this service object. For more information on bound parameters, see "Working with Services" in the Getting Started Guide.
-
endpoint
(String|AWS.Endpoint)
—
The endpoint URI to send requests to. The default endpoint is built from the configured
region
. The endpoint should be a string like'https://{service}.{region}.amazonaws.com'
or an Endpoint object. -
accessKeyId
(String)
—
your AWS access key ID.
-
secretAccessKey
(String)
—
your AWS secret access key.
-
sessionToken
(AWS.Credentials)
—
the optional AWS session token to sign requests with.
-
credentials
(AWS.Credentials)
—
the AWS credentials to sign requests with. You can either specify this object, or specify the accessKeyId and secretAccessKey options directly.
-
credentialProvider
(AWS.CredentialProviderChain)
—
the provider chain used to resolve credentials if no static
credentials
property is set. -
region
(String)
—
the region to send service requests to. See AWS.WAFV2.region for more information.
-
maxRetries
(Integer)
—
the maximum amount of retries to attempt with a request. See AWS.WAFV2.maxRetries for more information.
-
maxRedirects
(Integer)
—
the maximum amount of redirects to follow with a request. See AWS.WAFV2.maxRedirects for more information.
-
sslEnabled
(Boolean)
—
whether to enable SSL for requests.
-
paramValidation
(Boolean|map)
—
whether input parameters should be validated against the operation description before sending the request. Defaults to true. Pass a map to enable any of the following specific validation features:
- min [Boolean] — Validates that a value meets the min
constraint. This is enabled by default when paramValidation is set
to
true
. - max [Boolean] — Validates that a value meets the max constraint.
- pattern [Boolean] — Validates that a string value matches a regular expression.
- enum [Boolean] — Validates that a string value matches one of the allowable enum values.
- min [Boolean] — Validates that a value meets the min
constraint. This is enabled by default when paramValidation is set
to
-
computeChecksums
(Boolean)
—
whether to compute checksums for payload bodies when the service accepts it (currently supported in S3 only)
-
convertResponseTypes
(Boolean)
—
whether types are converted when parsing response data. Currently only supported for JSON based services. Turning this off may improve performance on large response payloads. Defaults to
true
. -
correctClockSkew
(Boolean)
—
whether to apply a clock skew correction and retry requests that fail because of an skewed client clock. Defaults to
false
. -
s3ForcePathStyle
(Boolean)
—
whether to force path style URLs for S3 objects.
-
s3BucketEndpoint
(Boolean)
—
whether the provided endpoint addresses an individual bucket (false if it addresses the root API endpoint). Note that setting this configuration option requires an
endpoint
to be provided explicitly to the service constructor. -
s3DisableBodySigning
(Boolean)
—
whether S3 body signing should be disabled when using signature version
v4
. Body signing can only be disabled when using https. Defaults totrue
. -
s3UsEast1RegionalEndpoint
('legacy'|'regional')
—
when region is set to 'us-east-1', whether to send s3 request to global endpoints or 'us-east-1' regional endpoints. This config is only applicable to S3 client. Defaults to
legacy
-
s3UseArnRegion
(Boolean)
—
whether to override the request region with the region inferred from requested resource's ARN. Only available for S3 buckets Defaults to
true
-
retryDelayOptions
(map)
—
A set of options to configure the retry delay on retryable errors. Currently supported options are:
- base [Integer] — The base number of milliseconds to use in the exponential backoff for operation retries. Defaults to 100 ms for all services except DynamoDB, where it defaults to 50ms.
- customBackoff [function] — A custom function that accepts a
retry count and error and returns the amount of time to delay in
milliseconds. If the result is a non-zero negative value, no further
retry attempts will be made. The
base
option will be ignored if this option is supplied. The function is only called for retryable errors.
-
httpOptions
(map)
—
A set of options to pass to the low-level HTTP request. Currently supported options are:
- proxy [String] — the URL to proxy requests through
- agent [http.Agent, https.Agent] — the Agent object to perform
HTTP requests with. Used for connection pooling. Defaults to the global
agent (
http.globalAgent
) for non-SSL connections. Note that for SSL connections, a special Agent object is used in order to enable peer certificate verification. This feature is only available in the Node.js environment. - connectTimeout [Integer] — Sets the socket to timeout after
failing to establish a connection with the server after
connectTimeout
milliseconds. This timeout has no effect once a socket connection has been established. - timeout [Integer] — Sets the socket to timeout after timeout milliseconds of inactivity on the socket. Defaults to two minutes (120000).
- xhrAsync [Boolean] — Whether the SDK will send asynchronous HTTP requests. Used in the browser environment only. Set to false to send requests synchronously. Defaults to true (async on).
- xhrWithCredentials [Boolean] — Sets the "withCredentials" property of an XMLHttpRequest object. Used in the browser environment only. Defaults to false.
-
apiVersion
(String, Date)
—
a String in YYYY-MM-DD format (or a date) that represents the latest possible API version that can be used in all services (unless overridden by
apiVersions
). Specify 'latest' to use the latest possible version. -
apiVersions
(map<String, String|Date>)
—
a map of service identifiers (the lowercase service class name) with the API version to use when instantiating a service. Specify 'latest' for each individual that can use the latest available version.
-
logger
(#write, #log)
—
an object that responds to .write() (like a stream) or .log() (like the console object) in order to log information about requests
-
systemClockOffset
(Number)
—
an offset value in milliseconds to apply to all signing times. Use this to compensate for clock skew when your system may be out of sync with the service time. Note that this configuration option can only be applied to the global
AWS.config
object and cannot be overridden in service-specific configuration. Defaults to 0 milliseconds. -
signatureVersion
(String)
—
the signature version to sign requests with (overriding the API configuration). Possible values are: 'v2', 'v3', 'v4'.
-
signatureCache
(Boolean)
—
whether the signature to sign requests with (overriding the API configuration) is cached. Only applies to the signature version 'v4'. Defaults to
true
. -
dynamoDbCrc32
(Boolean)
—
whether to validate the CRC32 checksum of HTTP response bodies returned by DynamoDB. Default:
true
. -
useAccelerateEndpoint
(Boolean)
—
Whether to use the S3 Transfer Acceleration endpoint with the S3 service. Default:
false
. -
clientSideMonitoring
(Boolean)
—
whether to collect and publish this client's performance metrics of all its API requests.
-
endpointDiscoveryEnabled
(Boolean|undefined)
—
whether to call operations with endpoints given by service dynamically. Setting this
-
endpointCacheSize
(Number)
—
the size of the global cache storing endpoints from endpoint discovery operations. Once endpoint cache is created, updating this setting cannot change existing cache size. Defaults to 1000
-
hostPrefixEnabled
(Boolean)
—
whether to marshal request parameters to the prefix of hostname. Defaults to
true
. -
stsRegionalEndpoints
('legacy'|'regional')
—
whether to send sts request to global endpoints or regional endpoints. Defaults to 'legacy'.
-
useFipsEndpoint
(Boolean)
—
Enables FIPS compatible endpoints. Defaults to
false
. -
useDualstackEndpoint
(Boolean)
—
Enables IPv6 dualstack endpoint. Defaults to
false
.
Property Details
Method Details
associateWebACL(params = {}, callback) ⇒ AWS.Request
Associates a web ACL with a regional application resource, to protect the resource. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
For Amazon CloudFront, don't use this call. Instead, use your CloudFront distribution configuration. To associate a web ACL, in the CloudFront call
UpdateDistribution
, set the web ACL ID to the Amazon Resource Name (ARN) of the web ACL. For information, see UpdateDistribution in the Amazon CloudFront Developer Guide.Required permissions for customer-managed IAM policies
This call requires permissions that are specific to the protected resource type. For details, see Permissions for AssociateWebACL in the WAF Developer Guide.
Temporary inconsistencies during updates
When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
The following are examples of the temporary inconsistencies that you might notice during change propagation:
-
After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
-
After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
-
After you change a rule action setting, you might see the old action in some places and the new action in others.
-
After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
Service Reference:
Examples:
Calling the associateWebACL operation
var params = { ResourceArn: 'STRING_VALUE', /* required */ WebACLArn: 'STRING_VALUE' /* required */ }; wafv2.associateWebACL(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
WebACLArn
— (String
)The Amazon Resource Name (ARN) of the web ACL that you want to associate with the resource.
ResourceArn
— (String
)The Amazon Resource Name (ARN) of the resource to associate with the web ACL.
The ARN must be in one of the following formats:
-
For an Application Load Balancer:
arn:partition:elasticloadbalancing:region:account-id:loadbalancer/app/load-balancer-name/load-balancer-id
-
For an Amazon API Gateway REST API:
arn:partition:apigateway:region::/restapis/api-id/stages/stage-name
-
For an AppSync GraphQL API:
arn:partition:appsync:region:account-id:apis/GraphQLApiId
-
For an Amazon Cognito user pool:
arn:partition:cognito-idp:region:account-id:userpool/user-pool-id
-
For an App Runner service:
arn:partition:apprunner:region:account-id:service/apprunner-service-name/apprunner-service-id
-
For an Amazon Web Services Verified Access instance:
arn:partition:ec2:region:account-id:verified-access-instance/instance-id
-
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
checkCapacity(params = {}, callback) ⇒ AWS.Request
Returns the web ACL capacity unit (WCU) requirements for a specified scope and set of rules. You can use this to check the capacity requirements for the rules you want to use in a RuleGroup or WebACL.
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.
Service Reference:
Examples:
Calling the checkCapacity operation
var params = { Rules: [ /* required */ { Name: 'STRING_VALUE', /* required */ Priority: 'NUMBER_VALUE', /* required */ Statement: { /* Statement */ /* required */ AndStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, ByteMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, PositionalConstraint: EXACTLY | STARTS_WITH | ENDS_WITH | CONTAINS | CONTAINS_WORD, /* required */ SearchString: Buffer.from('...') || 'STRING_VALUE' /* Strings will be Base-64 encoded on your behalf */, /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, GeoMatchStatement: { CountryCodes: [ AF | AX | AL | DZ | AS | AD | AO | AI | AQ | AG | AR | AM | AW | AU | AT | AZ | BS | BH | BD | BB | BY | BE | BZ | BJ | BM | BT | BO | BQ | BA | BW | BV | BR | IO | BN | BG | BF | BI | KH | CM | CA | CV | KY | CF | TD | CL | CN | CX | CC | CO | KM | CG | CD | CK | CR | CI | HR | CU | CW | CY | CZ | DK | DJ | DM | DO | EC | EG | SV | GQ | ER | EE | ET | FK | FO | FJ | FI | FR | GF | PF | TF | GA | GM | GE | DE | GH | GI | GR | GL | GD | GP | GU | GT | GG | GN | GW | GY | HT | HM | VA | HN | HK | HU | IS | IN | ID | IR | IQ | IE | IM | IL | IT | JM | JP | JE | JO | KZ | KE | KI | KP | KR | KW | KG | LA | LV | LB | LS | LR | LY | LI | LT | LU | MO | MK | MG | MW | MY | MV | ML | MT | MH | MQ | MR | MU | YT | MX | FM | MD | MC | MN | ME | MS | MA | MZ | MM | NA | NR | NP | NL | NC | NZ | NI | NE | NG | NU | NF | MP | NO | OM | PK | PW | PS | PA | PG | PY | PE | PH | PN | PL | PT | PR | QA | RE | RO | RU | RW | BL | SH | KN | LC | MF | PM | VC | WS | SM | ST | SA | SN | RS | SC | SL | SG | SX | SK | SI | SB | SO | ZA | GS | SS | ES | LK | SD | SR | SJ | SZ | SE | CH | SY | TW | TJ | TZ | TH | TL | TG | TK | TO | TT | TN | TR | TM | TC | TV | UG | UA | AE | GB | US | UM | UY | UZ | VU | VE | VN | VG | VI | WF | EH | YE | ZM | ZW | XK, /* more items */ ], ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ } }, IPSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ IPSetForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE', /* required */ Position: FIRST | LAST | ANY /* required */ } }, LabelMatchStatement: { Key: 'STRING_VALUE', /* required */ Scope: LABEL | NAMESPACE /* required */ }, ManagedRuleGroupStatement: { Name: 'STRING_VALUE', /* required */ VendorName: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ManagedRuleGroupConfigs: [ { AWSManagedRulesACFPRuleSet: { CreationPath: 'STRING_VALUE', /* required */ RegistrationPagePath: 'STRING_VALUE', /* required */ RequestInspection: { /* required */ PayloadType: JSON | FORM_ENCODED, /* required */ AddressFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], EmailField: { Identifier: 'STRING_VALUE' /* required */ }, PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PhoneNumberFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, EnableRegexInPath: true || false, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesATPRuleSet: { LoginPath: 'STRING_VALUE', /* required */ EnableRegexInPath: true || false, RequestInspection: { PasswordField: { /* required */ Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, /* required */ UsernameField: { /* required */ Identifier: 'STRING_VALUE' /* required */ } }, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesBotControlRuleSet: { InspectionLevel: COMMON | TARGETED, /* required */ EnableMachineLearning: true || false }, LoginPath: 'STRING_VALUE', PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ScopeDownStatement: /* recursive Statement */, Version: 'STRING_VALUE' }, NotStatement: { Statement: /* recursive Statement */ }, OrStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, RateBasedStatement: { AggregateKeyType: IP | FORWARDED_IP | CUSTOM_KEYS | CONSTANT, /* required */ Limit: 'NUMBER_VALUE', /* required */ CustomKeys: [ { Cookie: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, ForwardedIP: { }, HTTPMethod: { }, Header: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, IP: { }, LabelNamespace: { Namespace: 'STRING_VALUE' /* required */ }, QueryArgument: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, QueryString: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, UriPath: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, /* more items */ ], EvaluationWindowSec: 'NUMBER_VALUE', ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ }, ScopeDownStatement: /* recursive Statement */ }, RegexMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, RegexString: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RegexPatternSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RuleGroupReferenceStatement: { ARN: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, SizeConstraintStatement: { ComparisonOperator: EQ | NE | LE | LT | GE | GT, /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, Size: 'NUMBER_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, SqliMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ], SensitivityLevel: LOW | HIGH }, XssMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, VisibilityConfig: { /* required */ CloudWatchMetricsEnabled: true || false, /* required */ MetricName: 'STRING_VALUE', /* required */ SampledRequestsEnabled: true || false /* required */ }, Action: { Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, CaptchaConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, ChallengeConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, OverrideAction: { Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, None: { } }, RuleLabels: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, /* more items */ ], Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.checkCapacity(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Rules
— (Array<map>
)An array of Rule that you're configuring to use in a rule group or web ACL.
Name
— required — (String
)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'sVisibilityConfig
settings. WAF doesn't automatically update the metric name when you update the rule name.Priority
— required — (Integer
)If you define more than one
Rule
in aWebACL
, WAF evaluates each request against theRules
in order based on the value ofPriority
. WAF processes rules with lower priority first. The priorities don't need to be consecutive, but they must all be different.Statement
— required — (map
)The WAF processing statement for the rule, for example ByteMatchStatement or SizeConstraintStatement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.ManagedRuleGroupStatement
— (map
)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 aNotStatement
orOrStatement
. 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.Note: You are charged additional fees when you use the WAF Bot Control managed rule groupAWSManagedRulesBotControlRuleSet
, the WAF Fraud Control account takeover prevention (ATP) managed rule groupAWSManagedRulesATPRuleSet
, or the WAF Fraud Control account creation fraud prevention (ACFP) managed rule groupAWSManagedRulesACFPRuleSet
. For more information, see WAF Pricing.VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Action
— (map
)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
andManagedRuleGroupStatement
.You must specify either this
Action
setting or the ruleOverrideAction
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.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
-
OverrideAction
— (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
RuleLabels
— (Array<map>
)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
, oripset
.
For example,
myLabelName
ornameSpace1:nameSpace2:myLabelName
.Name
— required — (String
)The label string.
-
VisibilityConfig
— required — (map
)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.SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations. If you don't specify this, WAF uses theCAPTCHA
configuration that's defined for the web ACL.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:Capacity
— (Integer
)The capacity required by the rules and scope.
-
(AWS.Response)
—
Returns:
createAPIKey(params = {}, callback) ⇒ AWS.Request
Creates an API key that contains a set of token domains.
API keys are required for the integration of the CAPTCHA API in your JavaScript client applications. The API lets you customize the placement and characteristics of the CAPTCHA puzzle for your end users. For more information about the CAPTCHA JavaScript integration, see WAF client application integration in the WAF Developer Guide.
You can use a single key for up to 5 domains. After you generate a key, you can copy it for use in your JavaScript integration.
Service Reference:
Examples:
Calling the createAPIKey operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ TokenDomains: [ /* required */ 'STRING_VALUE', /* more items */ ] }; wafv2.createAPIKey(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
TokenDomains
— (Array<String>
)The client application domains that you want to use this API key for.
Example JSON:
"TokenDomains": ["abc.com", "store.abc.com"]
Public suffixes aren't allowed. For example, you can't use
gov.au
orco.uk
as token domains.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:APIKey
— (String
)The generated, encrypted API key. You can copy this for use in your JavaScript CAPTCHA integration.
-
(AWS.Response)
—
Returns:
createIPSet(params = {}, callback) ⇒ AWS.Request
Creates an IPSet, which you use to identify web requests that originate from specific IP addresses or ranges of IP addresses. For example, if you're receiving a lot of requests from a ranges of IP addresses, you can configure WAF to block them using an IPSet that lists those IP addresses.
Service Reference:
Examples:
Calling the createIPSet operation
var params = { Addresses: [ /* required */ 'STRING_VALUE', /* more items */ ], IPAddressVersion: IPV4 | IPV6, /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ Description: 'STRING_VALUE', Tags: [ { Key: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] }; wafv2.createIPSet(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the IP set. You cannot change the name of an
IPSet
after you create it.Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Description
— (String
)A description of the IP set that helps with identification.
IPAddressVersion
— (String
)The version of the IP addresses, either
Possible values include:IPV4
orIPV6
."IPV4"
"IPV6"
Addresses
— (Array<String>
)Contains an array of strings that specifies zero or more IP addresses or blocks of IP addresses that you want WAF to inspect for in incoming requests. All addresses must be specified using Classless Inter-Domain Routing (CIDR) notation. WAF supports all IPv4 and IPv6 CIDR ranges except for
/0
.Example address strings:
-
For requests that originated from the IP address 192.0.2.44, specify
192.0.2.44/32
. -
For requests that originated from IP addresses from 192.0.2.0 to 192.0.2.255, specify
192.0.2.0/24
. -
For requests that originated from the IP address 1111:0000:0000:0000:0000:0000:0000:0111, specify
1111:0000:0000:0000:0000:0000:0000:0111/128
. -
For requests that originated from IP addresses 1111:0000:0000:0000:0000:0000:0000:0000 to 1111:0000:0000:0000:ffff:ffff:ffff:ffff, specify
1111:0000:0000:0000:0000:0000:0000:0000/64
.
For more information about CIDR notation, see the Wikipedia entry Classless Inter-Domain Routing.
Example JSON
Addresses
specifications:-
Empty array:
"Addresses": []
-
Array with one address:
"Addresses": ["192.0.2.44/32"]
-
Array with three addresses:
"Addresses": ["192.0.2.44/32", "192.0.2.0/24", "192.0.0.0/16"]
-
INVALID specification:
"Addresses": [""]
INVALID
-
Tags
— (Array<map>
)An array of key:value pairs to associate with the resource.
Key
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag key to describe a category of information, such as "customer." Tag keys are case-sensitive.
Value
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag value to describe a specific value within a category, such as "companyA" or "companyB." Tag values are case-sensitive.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:Summary
— (map
)High-level information about an IPSet, returned by operations like create and list. This provides information like the ID, that you can use to retrieve and manage an
IPSet
, and the ARN, that you provide to the IPSetReferenceStatement to use the address set in a Rule.Name
— (String
)The name of the IP set. You cannot change the name of an
IPSet
after you create it.Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Description
— (String
)A description of the IP set that helps with identification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
-
(AWS.Response)
—
Returns:
createRegexPatternSet(params = {}, callback) ⇒ AWS.Request
Creates a RegexPatternSet, which you reference in a RegexPatternSetReferenceStatement, to have WAF inspect a web request component for the specified patterns.
Service Reference:
Examples:
Calling the createRegexPatternSet operation
var params = { Name: 'STRING_VALUE', /* required */ RegularExpressionList: [ /* required */ { RegexString: 'STRING_VALUE' }, /* more items */ ], Scope: CLOUDFRONT | REGIONAL, /* required */ Description: 'STRING_VALUE', Tags: [ { Key: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] }; wafv2.createRegexPatternSet(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the set. You cannot change the name after you create the set.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Description
— (String
)A description of the set that helps with identification.
RegularExpressionList
— (Array<map>
)Array of regular expression strings.
RegexString
— (String
)The string representing the regular expression.
Tags
— (Array<map>
)An array of key:value pairs to associate with the resource.
Key
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag key to describe a category of information, such as "customer." Tag keys are case-sensitive.
Value
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag value to describe a specific value within a category, such as "companyA" or "companyB." Tag values are case-sensitive.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:Summary
— (map
)High-level information about a RegexPatternSet, returned by operations like create and list. This provides information like the ID, that you can use to retrieve and manage a
RegexPatternSet
, and the ARN, that you provide to the RegexPatternSetReferenceStatement to use the pattern set in a Rule.Name
— (String
)The name of the data type instance. You cannot change the name after you create the instance.
Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Description
— (String
)A description of the set that helps with identification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
-
(AWS.Response)
—
Returns:
createRuleGroup(params = {}, callback) ⇒ AWS.Request
Creates a RuleGroup per the specifications provided.
A rule group defines a collection of rules to inspect and control web requests that you can use in a WebACL. When you create a rule group, you define an immutable capacity limit. If you update a rule group, you must stay within the capacity. This allows others to reuse the rule group with confidence in its capacity requirements.
Service Reference:
Examples:
Calling the createRuleGroup operation
var params = { Capacity: 'NUMBER_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ VisibilityConfig: { /* required */ CloudWatchMetricsEnabled: true || false, /* required */ MetricName: 'STRING_VALUE', /* required */ SampledRequestsEnabled: true || false /* required */ }, CustomResponseBodies: { '<EntityName>': { Content: 'STRING_VALUE', /* required */ ContentType: TEXT_PLAIN | TEXT_HTML | APPLICATION_JSON /* required */ }, /* '<EntityName>': ... */ }, Description: 'STRING_VALUE', Rules: [ { Name: 'STRING_VALUE', /* required */ Priority: 'NUMBER_VALUE', /* required */ Statement: { /* Statement */ /* required */ AndStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, ByteMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, PositionalConstraint: EXACTLY | STARTS_WITH | ENDS_WITH | CONTAINS | CONTAINS_WORD, /* required */ SearchString: Buffer.from('...') || 'STRING_VALUE' /* Strings will be Base-64 encoded on your behalf */, /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, GeoMatchStatement: { CountryCodes: [ AF | AX | AL | DZ | AS | AD | AO | AI | AQ | AG | AR | AM | AW | AU | AT | AZ | BS | BH | BD | BB | BY | BE | BZ | BJ | BM | BT | BO | BQ | BA | BW | BV | BR | IO | BN | BG | BF | BI | KH | CM | CA | CV | KY | CF | TD | CL | CN | CX | CC | CO | KM | CG | CD | CK | CR | CI | HR | CU | CW | CY | CZ | DK | DJ | DM | DO | EC | EG | SV | GQ | ER | EE | ET | FK | FO | FJ | FI | FR | GF | PF | TF | GA | GM | GE | DE | GH | GI | GR | GL | GD | GP | GU | GT | GG | GN | GW | GY | HT | HM | VA | HN | HK | HU | IS | IN | ID | IR | IQ | IE | IM | IL | IT | JM | JP | JE | JO | KZ | KE | KI | KP | KR | KW | KG | LA | LV | LB | LS | LR | LY | LI | LT | LU | MO | MK | MG | MW | MY | MV | ML | MT | MH | MQ | MR | MU | YT | MX | FM | MD | MC | MN | ME | MS | MA | MZ | MM | NA | NR | NP | NL | NC | NZ | NI | NE | NG | NU | NF | MP | NO | OM | PK | PW | PS | PA | PG | PY | PE | PH | PN | PL | PT | PR | QA | RE | RO | RU | RW | BL | SH | KN | LC | MF | PM | VC | WS | SM | ST | SA | SN | RS | SC | SL | SG | SX | SK | SI | SB | SO | ZA | GS | SS | ES | LK | SD | SR | SJ | SZ | SE | CH | SY | TW | TJ | TZ | TH | TL | TG | TK | TO | TT | TN | TR | TM | TC | TV | UG | UA | AE | GB | US | UM | UY | UZ | VU | VE | VN | VG | VI | WF | EH | YE | ZM | ZW | XK, /* more items */ ], ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ } }, IPSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ IPSetForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE', /* required */ Position: FIRST | LAST | ANY /* required */ } }, LabelMatchStatement: { Key: 'STRING_VALUE', /* required */ Scope: LABEL | NAMESPACE /* required */ }, ManagedRuleGroupStatement: { Name: 'STRING_VALUE', /* required */ VendorName: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ManagedRuleGroupConfigs: [ { AWSManagedRulesACFPRuleSet: { CreationPath: 'STRING_VALUE', /* required */ RegistrationPagePath: 'STRING_VALUE', /* required */ RequestInspection: { /* required */ PayloadType: JSON | FORM_ENCODED, /* required */ AddressFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], EmailField: { Identifier: 'STRING_VALUE' /* required */ }, PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PhoneNumberFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, EnableRegexInPath: true || false, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesATPRuleSet: { LoginPath: 'STRING_VALUE', /* required */ EnableRegexInPath: true || false, RequestInspection: { PasswordField: { /* required */ Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, /* required */ UsernameField: { /* required */ Identifier: 'STRING_VALUE' /* required */ } }, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesBotControlRuleSet: { InspectionLevel: COMMON | TARGETED, /* required */ EnableMachineLearning: true || false }, LoginPath: 'STRING_VALUE', PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ScopeDownStatement: /* recursive Statement */, Version: 'STRING_VALUE' }, NotStatement: { Statement: /* recursive Statement */ }, OrStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, RateBasedStatement: { AggregateKeyType: IP | FORWARDED_IP | CUSTOM_KEYS | CONSTANT, /* required */ Limit: 'NUMBER_VALUE', /* required */ CustomKeys: [ { Cookie: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, ForwardedIP: { }, HTTPMethod: { }, Header: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, IP: { }, LabelNamespace: { Namespace: 'STRING_VALUE' /* required */ }, QueryArgument: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, QueryString: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, UriPath: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, /* more items */ ], EvaluationWindowSec: 'NUMBER_VALUE', ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ }, ScopeDownStatement: /* recursive Statement */ }, RegexMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, RegexString: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RegexPatternSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RuleGroupReferenceStatement: { ARN: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, SizeConstraintStatement: { ComparisonOperator: EQ | NE | LE | LT | GE | GT, /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, Size: 'NUMBER_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, SqliMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ], SensitivityLevel: LOW | HIGH }, XssMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, VisibilityConfig: { /* required */ CloudWatchMetricsEnabled: true || false, /* required */ MetricName: 'STRING_VALUE', /* required */ SampledRequestsEnabled: true || false /* required */ }, Action: { Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, CaptchaConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, ChallengeConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, OverrideAction: { Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, None: { } }, RuleLabels: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, /* more items */ ], Tags: [ { Key: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] }; wafv2.createRuleGroup(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the rule group. You cannot change the name of a rule group after you create it.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Capacity
— (Integer
)The web ACL capacity units (WCUs) required for this rule group.
When you create your own rule group, you define this, and you cannot change it after creation. When you add or modify the rules in a rule group, WAF enforces this limit. You can check the capacity for a set of rules using CheckCapacity.
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.
Description
— (String
)A description of the rule group that helps with identification.
Rules
— (Array<map>
)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.
Name
— required — (String
)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'sVisibilityConfig
settings. WAF doesn't automatically update the metric name when you update the rule name.Priority
— required — (Integer
)If you define more than one
Rule
in aWebACL
, WAF evaluates each request against theRules
in order based on the value ofPriority
. WAF processes rules with lower priority first. The priorities don't need to be consecutive, but they must all be different.Statement
— required — (map
)The WAF processing statement for the rule, for example ByteMatchStatement or SizeConstraintStatement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.ManagedRuleGroupStatement
— (map
)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 aNotStatement
orOrStatement
. 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.Note: You are charged additional fees when you use the WAF Bot Control managed rule groupAWSManagedRulesBotControlRuleSet
, the WAF Fraud Control account takeover prevention (ATP) managed rule groupAWSManagedRulesATPRuleSet
, or the WAF Fraud Control account creation fraud prevention (ACFP) managed rule groupAWSManagedRulesACFPRuleSet
. For more information, see WAF Pricing.VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Action
— (map
)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
andManagedRuleGroupStatement
.You must specify either this
Action
setting or the ruleOverrideAction
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.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
-
OverrideAction
— (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
RuleLabels
— (Array<map>
)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
, oripset
.
For example,
myLabelName
ornameSpace1:nameSpace2:myLabelName
.Name
— required — (String
)The label string.
-
VisibilityConfig
— required — (map
)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.SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations. If you don't specify this, WAF uses theCAPTCHA
configuration that's defined for the web ACL.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
VisibilityConfig
— (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
Tags
— (Array<map>
)An array of key:value pairs to associate with the resource.
Key
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag key to describe a category of information, such as "customer." Tag keys are case-sensitive.
Value
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag value to describe a specific value within a category, such as "companyA" or "companyB." Tag values are case-sensitive.
CustomResponseBodies
— (map<map>
)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 rule group, and then use them in the rules that you define in the rule group.
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.
ContentType
— required — (String
)The type of content in the payload that you are defining in the
Possible values include:Content
string."TEXT_PLAIN"
"TEXT_HTML"
"APPLICATION_JSON"
Content
— required — (String
)The payload of the custom response.
You can use JSON escape strings in JSON content. To do this, you must specify JSON content in the
ContentType
setting.For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:Summary
— (map
)High-level information about a RuleGroup, returned by operations like create and list. This provides information like the ID, that you can use to retrieve and manage a
RuleGroup
, and the ARN, that you provide to the RuleGroupReferenceStatement to use the rule group in a Rule.Name
— (String
)The name of the data type instance. You cannot change the name after you create the instance.
Id
— (String
)A unique identifier for the rule group. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Description
— (String
)A description of the rule group that helps with identification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
-
(AWS.Response)
—
Returns:
createWebACL(params = {}, callback) ⇒ AWS.Request
Creates a WebACL per the specifications provided.
A web ACL defines a collection of rules to use to inspect and control web requests. Each rule has a statement that defines what to look for in web requests and an action that WAF applies to requests that match the statement. In the web ACL, you assign a default action to take (allow, block) for any request that does not match any of the rules. The rules in a web ACL can be a combination of the types Rule, RuleGroup, and managed rule group. You can associate a web ACL with one or more Amazon Web Services resources to protect. The resources can be an Amazon CloudFront distribution, an Amazon API Gateway REST API, an Application Load Balancer, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
Service Reference:
Examples:
Calling the createWebACL operation
var params = { DefaultAction: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ VisibilityConfig: { /* required */ CloudWatchMetricsEnabled: true || false, /* required */ MetricName: 'STRING_VALUE', /* required */ SampledRequestsEnabled: true || false /* required */ }, AssociationConfig: { RequestBody: { '<AssociatedResourceType>': { DefaultSizeInspectionLimit: KB_16 | KB_32 | KB_48 | KB_64 /* required */ }, /* '<AssociatedResourceType>': ... */ } }, CaptchaConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, ChallengeConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, CustomResponseBodies: { '<EntityName>': { Content: 'STRING_VALUE', /* required */ ContentType: TEXT_PLAIN | TEXT_HTML | APPLICATION_JSON /* required */ }, /* '<EntityName>': ... */ }, Description: 'STRING_VALUE', Rules: [ { Name: 'STRING_VALUE', /* required */ Priority: 'NUMBER_VALUE', /* required */ Statement: { /* Statement */ /* required */ AndStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, ByteMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, PositionalConstraint: EXACTLY | STARTS_WITH | ENDS_WITH | CONTAINS | CONTAINS_WORD, /* required */ SearchString: Buffer.from('...') || 'STRING_VALUE' /* Strings will be Base-64 encoded on your behalf */, /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, GeoMatchStatement: { CountryCodes: [ AF | AX | AL | DZ | AS | AD | AO | AI | AQ | AG | AR | AM | AW | AU | AT | AZ | BS | BH | BD | BB | BY | BE | BZ | BJ | BM | BT | BO | BQ | BA | BW | BV | BR | IO | BN | BG | BF | BI | KH | CM | CA | CV | KY | CF | TD | CL | CN | CX | CC | CO | KM | CG | CD | CK | CR | CI | HR | CU | CW | CY | CZ | DK | DJ | DM | DO | EC | EG | SV | GQ | ER | EE | ET | FK | FO | FJ | FI | FR | GF | PF | TF | GA | GM | GE | DE | GH | GI | GR | GL | GD | GP | GU | GT | GG | GN | GW | GY | HT | HM | VA | HN | HK | HU | IS | IN | ID | IR | IQ | IE | IM | IL | IT | JM | JP | JE | JO | KZ | KE | KI | KP | KR | KW | KG | LA | LV | LB | LS | LR | LY | LI | LT | LU | MO | MK | MG | MW | MY | MV | ML | MT | MH | MQ | MR | MU | YT | MX | FM | MD | MC | MN | ME | MS | MA | MZ | MM | NA | NR | NP | NL | NC | NZ | NI | NE | NG | NU | NF | MP | NO | OM | PK | PW | PS | PA | PG | PY | PE | PH | PN | PL | PT | PR | QA | RE | RO | RU | RW | BL | SH | KN | LC | MF | PM | VC | WS | SM | ST | SA | SN | RS | SC | SL | SG | SX | SK | SI | SB | SO | ZA | GS | SS | ES | LK | SD | SR | SJ | SZ | SE | CH | SY | TW | TJ | TZ | TH | TL | TG | TK | TO | TT | TN | TR | TM | TC | TV | UG | UA | AE | GB | US | UM | UY | UZ | VU | VE | VN | VG | VI | WF | EH | YE | ZM | ZW | XK, /* more items */ ], ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ } }, IPSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ IPSetForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE', /* required */ Position: FIRST | LAST | ANY /* required */ } }, LabelMatchStatement: { Key: 'STRING_VALUE', /* required */ Scope: LABEL | NAMESPACE /* required */ }, ManagedRuleGroupStatement: { Name: 'STRING_VALUE', /* required */ VendorName: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ManagedRuleGroupConfigs: [ { AWSManagedRulesACFPRuleSet: { CreationPath: 'STRING_VALUE', /* required */ RegistrationPagePath: 'STRING_VALUE', /* required */ RequestInspection: { /* required */ PayloadType: JSON | FORM_ENCODED, /* required */ AddressFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], EmailField: { Identifier: 'STRING_VALUE' /* required */ }, PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PhoneNumberFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, EnableRegexInPath: true || false, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesATPRuleSet: { LoginPath: 'STRING_VALUE', /* required */ EnableRegexInPath: true || false, RequestInspection: { PasswordField: { /* required */ Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, /* required */ UsernameField: { /* required */ Identifier: 'STRING_VALUE' /* required */ } }, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesBotControlRuleSet: { InspectionLevel: COMMON | TARGETED, /* required */ EnableMachineLearning: true || false }, LoginPath: 'STRING_VALUE', PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ScopeDownStatement: /* recursive Statement */, Version: 'STRING_VALUE' }, NotStatement: { Statement: /* recursive Statement */ }, OrStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, RateBasedStatement: { AggregateKeyType: IP | FORWARDED_IP | CUSTOM_KEYS | CONSTANT, /* required */ Limit: 'NUMBER_VALUE', /* required */ CustomKeys: [ { Cookie: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, ForwardedIP: { }, HTTPMethod: { }, Header: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, IP: { }, LabelNamespace: { Namespace: 'STRING_VALUE' /* required */ }, QueryArgument: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, QueryString: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, UriPath: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, /* more items */ ], EvaluationWindowSec: 'NUMBER_VALUE', ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ }, ScopeDownStatement: /* recursive Statement */ }, RegexMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, RegexString: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RegexPatternSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RuleGroupReferenceStatement: { ARN: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, SizeConstraintStatement: { ComparisonOperator: EQ | NE | LE | LT | GE | GT, /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, Size: 'NUMBER_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, SqliMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ], SensitivityLevel: LOW | HIGH }, XssMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, VisibilityConfig: { /* required */ CloudWatchMetricsEnabled: true || false, /* required */ MetricName: 'STRING_VALUE', /* required */ SampledRequestsEnabled: true || false /* required */ }, Action: { Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, CaptchaConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, ChallengeConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, OverrideAction: { Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, None: { } }, RuleLabels: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, /* more items */ ], Tags: [ { Key: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ], TokenDomains: [ 'STRING_VALUE', /* more items */ ] }; wafv2.createWebACL(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the web ACL. You cannot change the name of a web ACL after you create it.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
DefaultAction
— (map
)The action to perform if none of the
Rules
contained in theWebACL
match.Block
— (map
)Specifies that WAF should block requests by default.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Specifies that WAF should allow requests by default.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Description
— (String
)A description of the web ACL that helps with identification.
Rules
— (Array<map>
)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.
Name
— required — (String
)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'sVisibilityConfig
settings. WAF doesn't automatically update the metric name when you update the rule name.Priority
— required — (Integer
)If you define more than one
Rule
in aWebACL
, WAF evaluates each request against theRules
in order based on the value ofPriority
. WAF processes rules with lower priority first. The priorities don't need to be consecutive, but they must all be different.Statement
— required — (map
)The WAF processing statement for the rule, for example ByteMatchStatement or SizeConstraintStatement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.ManagedRuleGroupStatement
— (map
)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 aNotStatement
orOrStatement
. 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.Note: You are charged additional fees when you use the WAF Bot Control managed rule groupAWSManagedRulesBotControlRuleSet
, the WAF Fraud Control account takeover prevention (ATP) managed rule groupAWSManagedRulesATPRuleSet
, or the WAF Fraud Control account creation fraud prevention (ACFP) managed rule groupAWSManagedRulesACFPRuleSet
. For more information, see WAF Pricing.VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Action
— (map
)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
andManagedRuleGroupStatement
.You must specify either this
Action
setting or the ruleOverrideAction
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.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
-
OverrideAction
— (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
RuleLabels
— (Array<map>
)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
, oripset
.
For example,
myLabelName
ornameSpace1:nameSpace2:myLabelName
.Name
— required — (String
)The label string.
-
VisibilityConfig
— required — (map
)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.SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations. If you don't specify this, WAF uses theCAPTCHA
configuration that's defined for the web ACL.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
VisibilityConfig
— (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
Tags
— (Array<map>
)An array of key:value pairs to associate with the resource.
Key
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag key to describe a category of information, such as "customer." Tag keys are case-sensitive.
Value
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag value to describe a specific value within a category, such as "companyA" or "companyB." Tag values are case-sensitive.
CustomResponseBodies
— (map<map>
)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.
ContentType
— required — (String
)The type of content in the payload that you are defining in the
Possible values include:Content
string."TEXT_PLAIN"
"TEXT_HTML"
"APPLICATION_JSON"
Content
— required — (String
)The payload of the custom response.
You can use JSON escape strings in JSON content. To do this, you must specify JSON content in the
ContentType
setting.For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations for rules that don't have their ownCaptchaConfig
settings. If you don't specify this, WAF uses its default settings forCaptchaConfig
.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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 forChallengeConfig
.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
TokenDomains
— (Array<String>
)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.
Example JSON:
"TokenDomains": { "mywebsite.com", "myotherwebsite.com" }
Public suffixes aren't allowed. For example, you can't use
gov.au
orco.uk
as token domains.AssociationConfig
— (map
)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).
Note: 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).
RequestBody
— (map<map>
)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.
Note: 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).
DefaultSizeInspectionLimit
— required — (String
)Specifies the maximum size of the web request body component that an associated CloudFront, API Gateway, Amazon Cognito, App Runner, or Verified Access resource should send to WAF for inspection. This applies to statements in the web ACL that inspect the body or JSON body.
Default:
Possible values include:16 KB (16,384 bytes)
"KB_16"
"KB_32"
"KB_48"
"KB_64"
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:Summary
— (map
)High-level information about a WebACL, returned by operations like create and list. This provides information like the ID, that you can use to retrieve and manage a
WebACL
, and the ARN, that you provide to operations like AssociateWebACL.Name
— (String
)The name of the web ACL. You cannot change the name of a web ACL after you create it.
Id
— (String
)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.
Description
— (String
)A description of the web ACL that helps with identification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
-
(AWS.Response)
—
Returns:
deleteAPIKey(params = {}, callback) ⇒ AWS.Request
Deletes the specified API key.
After you delete a key, it can take up to 24 hours for WAF to disallow use of the key in all regions.
Service Reference:
Examples:
Calling the deleteAPIKey operation
var params = { APIKey: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.deleteAPIKey(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
APIKey
— (String
)The encrypted API key that you want to delete.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
deleteFirewallManagerRuleGroups(params = {}, callback) ⇒ AWS.Request
Deletes all rule groups that are managed by Firewall Manager for the specified web ACL.
You can only use this if
ManagedByFirewallManager
is false in the specified WebACL.Service Reference:
Examples:
Calling the deleteFirewallManagerRuleGroups operation
var params = { WebACLArn: 'STRING_VALUE', /* required */ WebACLLockToken: 'STRING_VALUE' /* required */ }; wafv2.deleteFirewallManagerRuleGroups(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
WebACLArn
— (String
)The Amazon Resource Name (ARN) of the web ACL.
WebACLLockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextWebACLLockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
-
(AWS.Response)
—
Returns:
deleteIPSet(params = {}, callback) ⇒ AWS.Request
Deletes the specified IPSet.
Service Reference:
Examples:
Calling the deleteIPSet operation
var params = { Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.deleteIPSet(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the IP set. You cannot change the name of an
IPSet
after you create it.Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
deleteLoggingConfiguration(params = {}, callback) ⇒ AWS.Request
Deletes the LoggingConfiguration from the specified web ACL.
Service Reference:
Examples:
Calling the deleteLoggingConfiguration operation
var params = { ResourceArn: 'STRING_VALUE', /* required */ LogScope: CUSTOMER | SECURITY_LAKE, LogType: WAF_LOGS }; wafv2.deleteLoggingConfiguration(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
ResourceArn
— (String
)The Amazon Resource Name (ARN) of the web ACL from which you want to delete the LoggingConfiguration.
LogType
— (String
)Used to distinguish between various logging options. Currently, there is one option.
Default:
Possible values include:WAF_LOGS
"WAF_LOGS"
LogScope
— (String
)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:
Possible values include:CUSTOMER
"CUSTOMER"
"SECURITY_LAKE"
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
deletePermissionPolicy(params = {}, callback) ⇒ AWS.Request
Permanently deletes an IAM policy from the specified rule group.
You must be the owner of the rule group to perform this operation.
Service Reference:
Examples:
Calling the deletePermissionPolicy operation
var params = { ResourceArn: 'STRING_VALUE' /* required */ }; wafv2.deletePermissionPolicy(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
ResourceArn
— (String
)The Amazon Resource Name (ARN) of the rule group from which you want to delete the policy.
You must be the owner of the rule group to perform this operation.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
deleteRegexPatternSet(params = {}, callback) ⇒ AWS.Request
Deletes the specified RegexPatternSet.
Service Reference:
Examples:
Calling the deleteRegexPatternSet operation
var params = { Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.deleteRegexPatternSet(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the set. You cannot change the name after you create the set.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
deleteRuleGroup(params = {}, callback) ⇒ AWS.Request
Deletes the specified RuleGroup.
Service Reference:
Examples:
Calling the deleteRuleGroup operation
var params = { Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.deleteRuleGroup(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the rule group. You cannot change the name of a rule group after you create it.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the rule group. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
deleteWebACL(params = {}, callback) ⇒ AWS.Request
Deletes the specified WebACL.
You can only use this if
ManagedByFirewallManager
is false in the specified WebACL.Note: Before deleting any web ACL, first disassociate it from all resources.- To retrieve a list of the resources that are associated with a web ACL, use the following calls:
- For regional resources, call ListResourcesForWebACL.
- For Amazon CloudFront distributions, use the CloudFront call
ListDistributionsByWebACLId
. For information, see ListDistributionsByWebACLId in the Amazon CloudFront API Reference.
- To disassociate a resource from a web ACL, use the following calls:
- For regional resources, call DisassociateWebACL.
- For Amazon CloudFront distributions, provide an empty web ACL ID in the CloudFront call
UpdateDistribution
. For information, see UpdateDistribution in the Amazon CloudFront API Reference.
Service Reference:
Examples:
Calling the deleteWebACL operation
var params = { Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.deleteWebACL(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the web ACL. You cannot change the name of a web ACL after you create it.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)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.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
describeAllManagedProducts(params = {}, callback) ⇒ AWS.Request
Provides high-level information for the Amazon Web Services Managed Rules rule groups and Amazon Web Services Marketplace managed rule groups.
Service Reference:
Examples:
Calling the describeAllManagedProducts operation
var params = { Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.describeAllManagedProducts(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:ManagedProducts
— (Array<map>
)High-level information for the Amazon Web Services Managed Rules rule groups and Amazon Web Services Marketplace managed rule groups.
VendorName
— (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
ManagedRuleSetName
— (String
)The name of the managed rule group. For example,
AWSManagedRulesAnonymousIpList
orAWSManagedRulesATPRuleSet
.ProductId
— (String
)A unique identifier for the rule group. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
ProductLink
— (String
)For Amazon Web Services Marketplace managed rule groups only, the link to the rule group product page.
ProductTitle
— (String
)The display name for the managed rule group. For example,
Anonymous IP list
orAccount takeover prevention
.ProductDescription
— (String
)A short description of the managed rule group.
SnsTopicArn
— (String
)The Amazon resource name (ARN) of the Amazon Simple Notification Service SNS topic that's used to provide notification of changes to the managed rule group. You can subscribe to the SNS topic to receive notifications when the managed rule group is modified, such as for new versions and for version expiration. For more information, see the Amazon Simple Notification Service Developer Guide.
IsVersioningSupported
— (Boolean
)Indicates whether the rule group is versioned.
IsAdvancedManagedRuleSet
— (Boolean
)Indicates whether the rule group provides an advanced set of protections, such as the the Amazon Web Services Managed Rules rule groups that are used for WAF intelligent threat mitigation.
-
(AWS.Response)
—
Returns:
describeManagedProductsByVendor(params = {}, callback) ⇒ AWS.Request
Provides high-level information for the managed rule groups owned by a specific vendor.
Service Reference:
Examples:
Calling the describeManagedProductsByVendor operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ VendorName: 'STRING_VALUE' /* required */ }; wafv2.describeManagedProductsByVendor(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
VendorName
— (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:ManagedProducts
— (Array<map>
)High-level information for the managed rule groups owned by the specified vendor.
VendorName
— (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
ManagedRuleSetName
— (String
)The name of the managed rule group. For example,
AWSManagedRulesAnonymousIpList
orAWSManagedRulesATPRuleSet
.ProductId
— (String
)A unique identifier for the rule group. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
ProductLink
— (String
)For Amazon Web Services Marketplace managed rule groups only, the link to the rule group product page.
ProductTitle
— (String
)The display name for the managed rule group. For example,
Anonymous IP list
orAccount takeover prevention
.ProductDescription
— (String
)A short description of the managed rule group.
SnsTopicArn
— (String
)The Amazon resource name (ARN) of the Amazon Simple Notification Service SNS topic that's used to provide notification of changes to the managed rule group. You can subscribe to the SNS topic to receive notifications when the managed rule group is modified, such as for new versions and for version expiration. For more information, see the Amazon Simple Notification Service Developer Guide.
IsVersioningSupported
— (Boolean
)Indicates whether the rule group is versioned.
IsAdvancedManagedRuleSet
— (Boolean
)Indicates whether the rule group provides an advanced set of protections, such as the the Amazon Web Services Managed Rules rule groups that are used for WAF intelligent threat mitigation.
-
(AWS.Response)
—
Returns:
describeManagedRuleGroup(params = {}, callback) ⇒ AWS.Request
Provides high-level information for a managed rule group, including descriptions of the rules.
Service Reference:
Examples:
Calling the describeManagedRuleGroup operation
var params = { Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ VendorName: 'STRING_VALUE', /* required */ VersionName: 'STRING_VALUE' }; wafv2.describeManagedRuleGroup(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
VendorName
— (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
VersionName
— (String
)The version of the rule group. You can only use a version that is not scheduled for expiration. If you don't provide this, WAF uses the vendor's default version.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:VersionName
— (String
)The managed rule group's version.
SnsTopicArn
— (String
)The Amazon resource name (ARN) of the Amazon Simple Notification Service SNS topic that's used to provide notification of changes to the managed rule group. You can subscribe to the SNS topic to receive notifications when the managed rule group is modified, such as for new versions and for version expiration. For more information, see the Amazon Simple Notification Service Developer Guide.
Capacity
— (Integer
)The web ACL capacity units (WCUs) required for this rule group.
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.
Rules
— (Array<map>
)Name
— (String
)The name of the rule.
Action
— (map
)The action that WAF should take on a web request when it matches a rule's statement. Settings at the web ACL level can override the rule action setting.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
LabelNamespace
— (String
)The label namespace prefix for this rule group. All labels added by rules in this rule group have this prefix.
-
The syntax for the label namespace prefix for a managed rule group is the following:
awswaf:managed:<vendor>:<rule group 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>
-
AvailableLabels
— (Array<map>
)The labels that one or more rules in this rule group add to matching web requests. These labels are defined in the
RuleLabels
for a Rule.Name
— (String
)An individual label specification.
ConsumedLabels
— (Array<map>
)The labels that one or more rules in this rule group match against in label match statements. These labels are defined in a
LabelMatchStatement
specification, in the Statement definition of a rule.Name
— (String
)An individual label specification.
-
(AWS.Response)
—
Returns:
disassociateWebACL(params = {}, callback) ⇒ AWS.Request
Disassociates the specified regional application resource from any existing web ACL association. A resource can have at most one web ACL association. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
For Amazon CloudFront, don't use this call. Instead, use your CloudFront distribution configuration. To disassociate a web ACL, provide an empty web ACL ID in the CloudFront call
UpdateDistribution
. For information, see UpdateDistribution in the Amazon CloudFront API Reference.Required permissions for customer-managed IAM policies
This call requires permissions that are specific to the protected resource type. For details, see Permissions for DisassociateWebACL in the WAF Developer Guide.
Service Reference:
Examples:
Calling the disassociateWebACL operation
var params = { ResourceArn: 'STRING_VALUE' /* required */ }; wafv2.disassociateWebACL(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
ResourceArn
— (String
)The Amazon Resource Name (ARN) of the resource to disassociate from the web ACL.
The ARN must be in one of the following formats:
-
For an Application Load Balancer:
arn:partition:elasticloadbalancing:region:account-id:loadbalancer/app/load-balancer-name/load-balancer-id
-
For an Amazon API Gateway REST API:
arn:partition:apigateway:region::/restapis/api-id/stages/stage-name
-
For an AppSync GraphQL API:
arn:partition:appsync:region:account-id:apis/GraphQLApiId
-
For an Amazon Cognito user pool:
arn:partition:cognito-idp:region:account-id:userpool/user-pool-id
-
For an App Runner service:
arn:partition:apprunner:region:account-id:service/apprunner-service-name/apprunner-service-id
-
For an Amazon Web Services Verified Access instance:
arn:partition:ec2:region:account-id:verified-access-instance/instance-id
-
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
generateMobileSdkReleaseUrl(params = {}, callback) ⇒ AWS.Request
Generates a presigned download URL for the specified release of the mobile SDK.
The mobile SDK is not generally available. Customers who have access to the mobile SDK can use it to establish and manage WAF tokens for use in HTTP(S) requests from a mobile device to WAF. For more information, see WAF client application integration in the WAF Developer Guide.
Service Reference:
Examples:
Calling the generateMobileSdkReleaseUrl operation
var params = { Platform: IOS | ANDROID, /* required */ ReleaseVersion: 'STRING_VALUE' /* required */ }; wafv2.generateMobileSdkReleaseUrl(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Platform
— (String
)The device platform.
Possible values include:"IOS"
"ANDROID"
ReleaseVersion
— (String
)The release version. For the latest available version, specify
LATEST
.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:Url
— (String
)The presigned download URL for the specified SDK release.
-
(AWS.Response)
—
Returns:
getDecryptedAPIKey(params = {}, callback) ⇒ AWS.Request
Returns your API key in decrypted form. Use this to check the token domains that you have defined for the key.
API keys are required for the integration of the CAPTCHA API in your JavaScript client applications. The API lets you customize the placement and characteristics of the CAPTCHA puzzle for your end users. For more information about the CAPTCHA JavaScript integration, see WAF client application integration in the WAF Developer Guide.
Service Reference:
Examples:
Calling the getDecryptedAPIKey operation
var params = { APIKey: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.getDecryptedAPIKey(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
APIKey
— (String
)The encrypted API key.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:TokenDomains
— (Array<String>
)The token domains that are defined in this API key.
CreationTimestamp
— (Date
)The date and time that the key was created.
-
(AWS.Response)
—
Returns:
getIPSet(params = {}, callback) ⇒ AWS.Request
Examples:
Calling the getIPSet operation
var params = { Id: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.getIPSet(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the IP set. You cannot change the name of an
IPSet
after you create it.Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:IPSet
— (map
)Name
— required — (String
)The name of the IP set. You cannot change the name of an
IPSet
after you create it.Id
— required — (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
ARN
— required — (String
)The Amazon Resource Name (ARN) of the entity.
Description
— (String
)A description of the IP set that helps with identification.
IPAddressVersion
— required — (String
)The version of the IP addresses, either
Possible values include:IPV4
orIPV6
."IPV4"
"IPV6"
Addresses
— required — (Array<String>
)Contains an array of strings that specifies zero or more IP addresses or blocks of IP addresses that you want WAF to inspect for in incoming requests. All addresses must be specified using Classless Inter-Domain Routing (CIDR) notation. WAF supports all IPv4 and IPv6 CIDR ranges except for
/0
.Example address strings:
-
For requests that originated from the IP address 192.0.2.44, specify
192.0.2.44/32
. -
For requests that originated from IP addresses from 192.0.2.0 to 192.0.2.255, specify
192.0.2.0/24
. -
For requests that originated from the IP address 1111:0000:0000:0000:0000:0000:0000:0111, specify
1111:0000:0000:0000:0000:0000:0000:0111/128
. -
For requests that originated from IP addresses 1111:0000:0000:0000:0000:0000:0000:0000 to 1111:0000:0000:0000:ffff:ffff:ffff:ffff, specify
1111:0000:0000:0000:0000:0000:0000:0000/64
.
For more information about CIDR notation, see the Wikipedia entry Classless Inter-Domain Routing.
Example JSON
Addresses
specifications:-
Empty array:
"Addresses": []
-
Array with one address:
"Addresses": ["192.0.2.44/32"]
-
Array with three addresses:
"Addresses": ["192.0.2.44/32", "192.0.2.0/24", "192.0.0.0/16"]
-
INVALID specification:
"Addresses": [""]
INVALID
-
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
-
(AWS.Response)
—
Returns:
getLoggingConfiguration(params = {}, callback) ⇒ AWS.Request
Returns the LoggingConfiguration for the specified web ACL.
Service Reference:
Examples:
Calling the getLoggingConfiguration operation
var params = { ResourceArn: 'STRING_VALUE', /* required */ LogScope: CUSTOMER | SECURITY_LAKE, LogType: WAF_LOGS }; wafv2.getLoggingConfiguration(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
ResourceArn
— (String
)The Amazon Resource Name (ARN) of the web ACL for which you want to get the LoggingConfiguration.
LogType
— (String
)Used to distinguish between various logging options. Currently, there is one option.
Default:
Possible values include:WAF_LOGS
"WAF_LOGS"
LogScope
— (String
)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:
Possible values include:CUSTOMER
"CUSTOMER"
"SECURITY_LAKE"
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:LoggingConfiguration
— (map
)The LoggingConfiguration for the specified web ACL.
ResourceArn
— required — (String
)The Amazon Resource Name (ARN) of the web ACL that you want to associate with
LogDestinationConfigs
.LogDestinationConfigs
— required — (Array<String>
)The logging destination configuration that you want to associate with the web ACL.
Note: You can associate one logging destination to a web ACL.RedactedFields
— (Array<map>
)The parts of the request that you want to keep out of the logs.
For example, if you redact the
SingleHeader
field, theHEADER
field in the logs will beREDACTED
for all rules that use theSingleHeader
FieldToMatch
setting.Redaction applies only to the component that's specified in the rule's
FieldToMatch
setting, so theSingleHeader
redaction doesn't apply to rules that use theHeaders
FieldToMatch
.Note: You can specify only the following fields for redaction:UriPath
,QueryString
,SingleHeader
, andMethod
.Note: 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.SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ManagedByFirewallManager
— (Boolean
)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.
LoggingFilter
— (map
)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.
Filters
— required — (Array<map>
)The filters that you want to apply to the logs.
Behavior
— required — (String
)How to handle logs that satisfy the filter's conditions and requirement.
Possible values include:"KEEP"
"DROP"
Requirement
— required — (String
)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.
Possible values include:"MEETS_ALL"
"MEETS_ANY"
Conditions
— required — (Array<map>
)Match conditions for the filter.
ActionCondition
— (map
)A single action condition. This is the action setting that a log record must contain in order to meet the condition.
Action
— required — (String
)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
Possible values include:EXCLUDED_AS_COUNT
matches on excluded rules and also on rules that have a rule action override of Count."ALLOW"
"BLOCK"
"COUNT"
"CAPTCHA"
"CHALLENGE"
"EXCLUDED_AS_COUNT"
LabelNameCondition
— (map
)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.
LabelName
— required — (String
)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.
DefaultBehavior
— required — (String
)Default handling for logs that don't match any of the specified filtering conditions.
Possible values include:"KEEP"
"DROP"
LogType
— (String
)Used to distinguish between various logging options. Currently, there is one option.
Default:
Possible values include:WAF_LOGS
"WAF_LOGS"
LogScope
— (String
)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:
Possible values include:CUSTOMER
"CUSTOMER"
"SECURITY_LAKE"
-
(AWS.Response)
—
Returns:
getManagedRuleSet(params = {}, callback) ⇒ AWS.Request
Retrieves the specified managed rule set.
Note: This is intended for use only by vendors of managed rule sets. Vendors are Amazon Web Services and Amazon Web Services Marketplace sellers. Vendors, you can use the managed rule set APIs to provide controlled rollout of your versioned managed rule group offerings for your customers. The APIs areListManagedRuleSets
,GetManagedRuleSet
,PutManagedRuleSetVersions
, andUpdateManagedRuleSetVersionExpiryDate
.Service Reference:
Examples:
Calling the getManagedRuleSet operation
var params = { Id: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.getManagedRuleSet(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the managed rule set. You use this, along with the rule set ID, to identify the rule set.
This name is assigned to the corresponding managed rule group, which your customers can access and use.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the managed rule set. The ID is returned in the responses to commands like
list
. You provide it to operations likeget
andupdate
.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:ManagedRuleSet
— (map
)The managed rule set that you requested.
Name
— required — (String
)The name of the managed rule set. You use this, along with the rule set ID, to identify the rule set.
This name is assigned to the corresponding managed rule group, which your customers can access and use.
Id
— required — (String
)A unique identifier for the managed rule set. The ID is returned in the responses to commands like
list
. You provide it to operations likeget
andupdate
.ARN
— required — (String
)The Amazon Resource Name (ARN) of the entity.
Description
— (String
)A description of the set that helps with identification.
PublishedVersions
— (map<map>
)The versions of this managed rule set that are available for use by customers.
AssociatedRuleGroupArn
— (String
)The Amazon Resource Name (ARN) of the vendor rule group that's used to define the published version of your managed rule group.
Capacity
— (Integer
)The web ACL capacity units (WCUs) required for this rule group.
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.
ForecastedLifetime
— (Integer
)The amount of time you expect this version of your managed rule group to last, in days.
PublishTimestamp
— (Date
)The time that you first published this version.
Times are in Coordinated Universal Time (UTC) format. UTC format includes the special designator, Z. For example, "2016-09-27T14:50Z".
LastUpdateTimestamp
— (Date
)The last time that you updated this version.
Times are in Coordinated Universal Time (UTC) format. UTC format includes the special designator, Z. For example, "2016-09-27T14:50Z".
ExpiryTimestamp
— (Date
)The time that this version is set to expire.
Times are in Coordinated Universal Time (UTC) format. UTC format includes the special designator, Z. For example, "2016-09-27T14:50Z".
RecommendedVersion
— (String
)The version that you would like your customers to use.
LabelNamespace
— (String
)The label namespace prefix for the managed rule groups that are offered to customers from this managed rule set. All labels that are added by rules in the managed rule group have this prefix.
-
The syntax for the label namespace prefix for a managed rule group is the following:
awswaf:managed:<vendor>:<rule group 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>
-
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
-
(AWS.Response)
—
Returns:
getMobileSdkRelease(params = {}, callback) ⇒ AWS.Request
Retrieves information for the specified mobile SDK release, including release notes and tags.
The mobile SDK is not generally available. Customers who have access to the mobile SDK can use it to establish and manage WAF tokens for use in HTTP(S) requests from a mobile device to WAF. For more information, see WAF client application integration in the WAF Developer Guide.
Service Reference:
Examples:
Calling the getMobileSdkRelease operation
var params = { Platform: IOS | ANDROID, /* required */ ReleaseVersion: 'STRING_VALUE' /* required */ }; wafv2.getMobileSdkRelease(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Platform
— (String
)The device platform.
Possible values include:"IOS"
"ANDROID"
ReleaseVersion
— (String
)The release version. For the latest available version, specify
LATEST
.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:MobileSdkRelease
— (map
)Information for a specified SDK release, including release notes and tags.
ReleaseVersion
— (String
)The release version.
Timestamp
— (Date
)The timestamp of the release.
ReleaseNotes
— (String
)Notes describing the release.
Tags
— (Array<map>
)Tags that are associated with the release.
Key
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag key to describe a category of information, such as "customer." Tag keys are case-sensitive.
Value
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag value to describe a specific value within a category, such as "companyA" or "companyB." Tag values are case-sensitive.
-
(AWS.Response)
—
Returns:
getPermissionPolicy(params = {}, callback) ⇒ AWS.Request
Returns the IAM policy that is attached to the specified rule group.
You must be the owner of the rule group to perform this operation.
Service Reference:
Examples:
Calling the getPermissionPolicy operation
var params = { ResourceArn: 'STRING_VALUE' /* required */ }; wafv2.getPermissionPolicy(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
ResourceArn
— (String
)The Amazon Resource Name (ARN) of the rule group for which you want to get the policy.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:Policy
— (String
)The IAM policy that is attached to the specified rule group.
-
(AWS.Response)
—
Returns:
getRateBasedStatementManagedKeys(params = {}, callback) ⇒ AWS.Request
Retrieves the IP addresses that are currently blocked by a rate-based rule instance. This is only available for rate-based rules that aggregate solely on the IP address or on the forwarded IP address.
The maximum number of addresses that can be blocked for a single rate-based rule instance is 10,000. If more than 10,000 addresses exceed the rate limit, those with the highest rates are blocked.
For a rate-based rule that you've defined inside a rule group, provide the name of the rule group reference statement in your request, in addition to the rate-based rule name and the web ACL name.
WAF monitors web requests and manages keys independently for each unique combination of web ACL, optional rule group, and rate-based rule. For example, if you define a rate-based rule inside a rule group, and then use the rule group in a web ACL, WAF monitors web requests and manages keys for that web ACL, rule group reference statement, and rate-based rule instance. If you use the same rule group in a second web ACL, WAF monitors web requests and manages keys for this second usage completely independent of your first.
Service Reference:
Examples:
Calling the getRateBasedStatementManagedKeys operation
var params = { RuleName: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ WebACLId: 'STRING_VALUE', /* required */ WebACLName: 'STRING_VALUE', /* required */ RuleGroupRuleName: 'STRING_VALUE' }; wafv2.getRateBasedStatementManagedKeys(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
WebACLName
— (String
)The name of the web ACL. You cannot change the name of a web ACL after you create it.
WebACLId
— (String
)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.
RuleGroupRuleName
— (String
)The name of the rule group reference statement in your web ACL. This is required only when you have the rate-based rule nested inside a rule group.
RuleName
— (String
)The name of the rate-based rule to get the keys for. If you have the rule defined inside a rule group that you're using in your web ACL, also provide the name of the rule group reference statement in the request parameter
RuleGroupRuleName
.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:ManagedKeysIPV4
— (map
)The keys that are of Internet Protocol version 4 (IPv4).
IPAddressVersion
— (String
)The version of the IP addresses, either
Possible values include:IPV4
orIPV6
."IPV4"
"IPV6"
Addresses
— (Array<String>
)The IP addresses that are currently blocked.
ManagedKeysIPV6
— (map
)The keys that are of Internet Protocol version 6 (IPv6).
IPAddressVersion
— (String
)The version of the IP addresses, either
Possible values include:IPV4
orIPV6
."IPV4"
"IPV6"
Addresses
— (Array<String>
)The IP addresses that are currently blocked.
-
(AWS.Response)
—
Returns:
getRegexPatternSet(params = {}, callback) ⇒ AWS.Request
Retrieves the specified RegexPatternSet.
Service Reference:
Examples:
Calling the getRegexPatternSet operation
var params = { Id: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.getRegexPatternSet(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the set. You cannot change the name after you create the set.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:RegexPatternSet
— (map
)Name
— (String
)The name of the set. You cannot change the name after you create the set.
Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
Description
— (String
)A description of the set that helps with identification.
RegularExpressionList
— (Array<map>
)The regular expression patterns in the set.
RegexString
— (String
)The string representing the regular expression.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
-
(AWS.Response)
—
Returns:
getRuleGroup(params = {}, callback) ⇒ AWS.Request
Retrieves the specified RuleGroup.
Service Reference:
Examples:
Calling the getRuleGroup operation
var params = { ARN: 'STRING_VALUE', Id: 'STRING_VALUE', Name: 'STRING_VALUE', Scope: CLOUDFRONT | REGIONAL }; wafv2.getRuleGroup(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the rule group. You cannot change the name of a rule group after you create it.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the rule group. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:RuleGroup
— (map
)Name
— required — (String
)The name of the rule group. You cannot change the name of a rule group after you create it.
Id
— required — (String
)A unique identifier for the rule group. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Capacity
— required — (Integer
)The web ACL capacity units (WCUs) required for this rule group.
When you create your own rule group, you define this, and you cannot change it after creation. When you add or modify the rules in a rule group, WAF enforces this limit. You can check the capacity for a set of rules using CheckCapacity.
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.
ARN
— required — (String
)The Amazon Resource Name (ARN) of the entity.
Description
— (String
)A description of the rule group that helps with identification.
Rules
— (Array<map>
)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.
Name
— required — (String
)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'sVisibilityConfig
settings. WAF doesn't automatically update the metric name when you update the rule name.Priority
— required — (Integer
)If you define more than one
Rule
in aWebACL
, WAF evaluates each request against theRules
in order based on the value ofPriority
. WAF processes rules with lower priority first. The priorities don't need to be consecutive, but they must all be different.Statement
— required — (map
)The WAF processing statement for the rule, for example ByteMatchStatement or SizeConstraintStatement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.ManagedRuleGroupStatement
— (map
)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 aNotStatement
orOrStatement
. 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.Note: You are charged additional fees when you use the WAF Bot Control managed rule groupAWSManagedRulesBotControlRuleSet
, the WAF Fraud Control account takeover prevention (ATP) managed rule groupAWSManagedRulesATPRuleSet
, or the WAF Fraud Control account creation fraud prevention (ACFP) managed rule groupAWSManagedRulesACFPRuleSet
. For more information, see WAF Pricing.VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Action
— (map
)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
andManagedRuleGroupStatement
.You must specify either this
Action
setting or the ruleOverrideAction
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.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
-
OverrideAction
— (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
RuleLabels
— (Array<map>
)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
, oripset
.
For example,
myLabelName
ornameSpace1:nameSpace2:myLabelName
.Name
— required — (String
)The label string.
-
VisibilityConfig
— required — (map
)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.SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations. If you don't specify this, WAF uses theCAPTCHA
configuration that's defined for the web ACL.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
VisibilityConfig
— required — (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
LabelNamespace
— (String
)The label namespace prefix for this rule group. All labels added by rules in this rule group have this prefix.
-
The syntax for the label namespace prefix for your rule groups is the following:
awswaf:<account ID>:rulegroup:<rule group 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>
-
CustomResponseBodies
— (map<map>
)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 rule group, and then use them in the rules that you define in the rule group.
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.
ContentType
— required — (String
)The type of content in the payload that you are defining in the
Possible values include:Content
string."TEXT_PLAIN"
"TEXT_HTML"
"APPLICATION_JSON"
Content
— required — (String
)The payload of the custom response.
You can use JSON escape strings in JSON content. To do this, you must specify JSON content in the
ContentType
setting.For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
AvailableLabels
— (Array<map>
)The labels that one or more rules in this rule group add to matching web requests. These labels are defined in the
RuleLabels
for a Rule.Name
— (String
)An individual label specification.
ConsumedLabels
— (Array<map>
)The labels that one or more rules in this rule group match against in label match statements. These labels are defined in a
LabelMatchStatement
specification, in the Statement definition of a rule.Name
— (String
)An individual label specification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
-
(AWS.Response)
—
Returns:
getSampledRequests(params = {}, callback) ⇒ AWS.Request
Gets detailed information about a specified number of requests--a sample--that WAF randomly selects from among the first 5,000 requests that your Amazon Web Services resource received during a time range that you choose. You can specify a sample size of up to 500 requests, and you can specify any time range in the previous three hours.
GetSampledRequests
returns a time range, which is usually the time range that you specified. However, if your resource (such as a CloudFront distribution) received 5,000 requests before the specified time range elapsed,GetSampledRequests
returns an updated time range. This new time range indicates the actual period during which WAF selected the requests in the sample.Service Reference:
Examples:
Calling the getSampledRequests operation
var params = { MaxItems: 'NUMBER_VALUE', /* required */ RuleMetricName: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ TimeWindow: { /* required */ EndTime: new Date || 'Wed Dec 31 1969 16:00:00 GMT-0800 (PST)' || 123456789, /* required */ StartTime: new Date || 'Wed Dec 31 1969 16:00:00 GMT-0800 (PST)' || 123456789 /* required */ }, WebAclArn: 'STRING_VALUE' /* required */ }; wafv2.getSampledRequests(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
WebAclArn
— (String
)The Amazon resource name (ARN) of the
WebACL
for which you want a sample of requests.RuleMetricName
— (String
)The metric name assigned to the
Rule
orRuleGroup
dimension for which you want a sample of requests.Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
TimeWindow
— (map
)The start date and time and the end date and time of the range for which you want
GetSampledRequests
to return a sample of requests. You must specify the times in Coordinated Universal Time (UTC) format. UTC format includes the special designator,Z
. For example,"2016-09-27T14:50Z"
. You can specify any time range in the previous three hours. If you specify a start time that's earlier than three hours ago, WAF sets it to three hours ago.StartTime
— required — (Date
)The beginning of the time range from which you want
GetSampledRequests
to return a sample of the requests that your Amazon Web Services resource received. You must specify the times in Coordinated Universal Time (UTC) format. UTC format includes the special designator,Z
. For example,"2016-09-27T14:50Z"
. You can specify any time range in the previous three hours.EndTime
— required — (Date
)The end of the time range from which you want
GetSampledRequests
to return a sample of the requests that your Amazon Web Services resource received. You must specify the times in Coordinated Universal Time (UTC) format. UTC format includes the special designator,Z
. For example,"2016-09-27T14:50Z"
. You can specify any time range in the previous three hours.
MaxItems
— (Integer
)The number of requests that you want WAF to return from among the first 5,000 requests that your Amazon Web Services resource received during the time range. If your resource received fewer requests than the value of
MaxItems
,GetSampledRequests
returns information about all of them.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:SampledRequests
— (Array<map>
)A complex type that contains detailed information about each of the requests in the sample.
Request
— required — (map
)A complex type that contains detailed information about the request.
ClientIP
— (String
)The IP address that the request originated from. If the web ACL is associated with a CloudFront distribution, this is the value of one of the following fields in CloudFront access logs:
-
c-ip
, if the viewer did not use an HTTP proxy or a load balancer to send the request -
x-forwarded-for
, if the viewer did use an HTTP proxy or a load balancer to send the request
-
Country
— (String
)The two-letter country code for the country that the request originated from. For a current list of country codes, see the Wikipedia entry ISO 3166-1 alpha-2.
URI
— (String
)The URI path of the request, which identifies the resource, for example,
/images/daily-ad.jpg
.Method
— (String
)The HTTP method specified in the sampled web request.
HTTPVersion
— (String
)The HTTP version specified in the sampled web request, for example,
HTTP/1.1
.Headers
— (Array<map>
)A complex type that contains the name and value for each header in the sampled web request.
Name
— (String
)The name of the HTTP header.
Value
— (String
)The value of the HTTP header.
Weight
— required — (Integer
)A value that indicates how one result in the response relates proportionally to other results in the response. For example, a result that has a weight of
2
represents roughly twice as many web requests as a result that has a weight of1
.Timestamp
— (Date
)The time at which WAF received the request from your Amazon Web Services resource, in Unix time format (in seconds).
Action
— (String
)The action that WAF applied to the request.
RuleNameWithinRuleGroup
— (String
)The name of the
Rule
that the request matched. For managed rule groups, the format for this name is<vendor name>#<managed rule group name>#<rule name>
. For your own rule groups, the format for this name is<rule group name>#<rule name>
. If the rule is not in a rule group, this field is absent.RequestHeadersInserted
— (Array<map>
)Custom request headers inserted by WAF into the request, according to the custom request configuration for the matching rule action.
Name
— (String
)The name of the HTTP header.
Value
— (String
)The value of the HTTP header.
ResponseCodeSent
— (Integer
)The response code that was sent for the request.
Labels
— (Array<map>
)Labels applied to the web request by matching rules. 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.
For example,
awswaf:111122223333:myRuleGroup:testRules:testNS1:testNS2:labelNameA
orawswaf:managed:aws:managed-rule-set:header:encoding:utf8
.Name
— required — (String
)The label string.
CaptchaResponse
— (map
)The
CAPTCHA
response for the request.ResponseCode
— (Integer
)The HTTP response code indicating the status of the
CAPTCHA
token in the web request. If the token is missing, invalid, or expired, this code is405 Method Not Allowed
.SolveTimestamp
— (Integer
)The time that the
CAPTCHA
was last solved for the supplied token.FailureReason
— (String
)The reason for failure, populated when the evaluation of the token fails.
Possible values include:"TOKEN_MISSING"
"TOKEN_EXPIRED"
"TOKEN_INVALID"
"TOKEN_DOMAIN_MISMATCH"
ChallengeResponse
— (map
)The
Challenge
response for the request.ResponseCode
— (Integer
)The HTTP response code indicating the status of the challenge token in the web request. If the token is missing, invalid, or expired, this code is
202 Request Accepted
.SolveTimestamp
— (Integer
)The time that the challenge was last solved for the supplied token.
FailureReason
— (String
)The reason for failure, populated when the evaluation of the token fails.
Possible values include:"TOKEN_MISSING"
"TOKEN_EXPIRED"
"TOKEN_INVALID"
"TOKEN_DOMAIN_MISMATCH"
OverriddenAction
— (String
)Used only for rule group rules that have a rule action override in place in the web ACL. This is the action that the rule group rule is configured for, and not the action that was applied to the request. The action that WAF applied is the
Action
value.
PopulationSize
— (Integer
)The total number of requests from which
GetSampledRequests
got a sample ofMaxItems
requests. IfPopulationSize
is less thanMaxItems
, the sample includes every request that your Amazon Web Services resource received during the specified time range.TimeWindow
— (map
)Usually,
TimeWindow
is the time range that you specified in theGetSampledRequests
request. However, if your Amazon Web Services resource received more than 5,000 requests during the time range that you specified in the request,GetSampledRequests
returns the time range for the first 5,000 requests. Times are in Coordinated Universal Time (UTC) format.StartTime
— required — (Date
)The beginning of the time range from which you want
GetSampledRequests
to return a sample of the requests that your Amazon Web Services resource received. You must specify the times in Coordinated Universal Time (UTC) format. UTC format includes the special designator,Z
. For example,"2016-09-27T14:50Z"
. You can specify any time range in the previous three hours.EndTime
— required — (Date
)The end of the time range from which you want
GetSampledRequests
to return a sample of the requests that your Amazon Web Services resource received. You must specify the times in Coordinated Universal Time (UTC) format. UTC format includes the special designator,Z
. For example,"2016-09-27T14:50Z"
. You can specify any time range in the previous three hours.
-
(AWS.Response)
—
Returns:
getWebACL(params = {}, callback) ⇒ AWS.Request
Examples:
Calling the getWebACL operation
var params = { Id: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL /* required */ }; wafv2.getWebACL(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the web ACL. You cannot change the name of a web ACL after you create it.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)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.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:WebACL
— (map
)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.
Name
— required — (String
)The name of the web ACL. You cannot change the name of a web ACL after you create it.
Id
— required — (String
)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 aWebACL
.ARN
— required — (String
)The Amazon Resource Name (ARN) of the web ACL that you want to associate with the resource.
DefaultAction
— required — (map
)The action to perform if none of the
Rules
contained in theWebACL
match.Block
— (map
)Specifies that WAF should block requests by default.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Specifies that WAF should allow requests by default.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Description
— (String
)A description of the web ACL that helps with identification.
Rules
— (Array<map>
)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.
Name
— required — (String
)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'sVisibilityConfig
settings. WAF doesn't automatically update the metric name when you update the rule name.Priority
— required — (Integer
)If you define more than one
Rule
in aWebACL
, WAF evaluates each request against theRules
in order based on the value ofPriority
. WAF processes rules with lower priority first. The priorities don't need to be consecutive, but they must all be different.Statement
— required — (map
)The WAF processing statement for the rule, for example ByteMatchStatement or SizeConstraintStatement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.ManagedRuleGroupStatement
— (map
)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 aNotStatement
orOrStatement
. 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.Note: You are charged additional fees when you use the WAF Bot Control managed rule groupAWSManagedRulesBotControlRuleSet
, the WAF Fraud Control account takeover prevention (ATP) managed rule groupAWSManagedRulesATPRuleSet
, or the WAF Fraud Control account creation fraud prevention (ACFP) managed rule groupAWSManagedRulesACFPRuleSet
. For more information, see WAF Pricing.VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Action
— (map
)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
andManagedRuleGroupStatement
.You must specify either this
Action
setting or the ruleOverrideAction
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.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
-
OverrideAction
— (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
RuleLabels
— (Array<map>
)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
, oripset
.
For example,
myLabelName
ornameSpace1:nameSpace2:myLabelName
.Name
— required — (String
)The label string.
-
VisibilityConfig
— required — (map
)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.SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations. If you don't specify this, WAF uses theCAPTCHA
configuration that's defined for the web ACL.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
VisibilityConfig
— required — (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
Capacity
— (Integer
)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.
PreProcessFirewallManagerRuleGroups
— (Array<map>
)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.
Name
— required — (String
)The name of the rule group. You cannot change the name of a rule group after you create it.
Priority
— required — (Integer
)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.
FirewallManagerStatement
— required — (map
)The processing guidance for an Firewall Manager rule. This is like a regular rule Statement, but it can only contain a rule group reference.
ManagedRuleGroupStatement
— (map
)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.
VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ScopeDownStatement
— (map
)An optional nested statement that narrows the scope of the web requests that are evaluated by the managed rule group. Requests are only evaluated by the rule group if they match the scope-down statement. You can use any nestable Statement in the scope-down statement, and you can nest statements at any level, the same as you can for a rule statement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
RuleGroupReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
OverrideAction
— required — (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
VisibilityConfig
— required — (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
PostProcessFirewallManagerRuleGroups
— (Array<map>
)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.
Name
— required — (String
)The name of the rule group. You cannot change the name of a rule group after you create it.
Priority
— required — (Integer
)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.
FirewallManagerStatement
— required — (map
)The processing guidance for an Firewall Manager rule. This is like a regular rule Statement, but it can only contain a rule group reference.
ManagedRuleGroupStatement
— (map
)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.
VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ScopeDownStatement
— (map
)An optional nested statement that narrows the scope of the web requests that are evaluated by the managed rule group. Requests are only evaluated by the rule group if they match the scope-down statement. You can use any nestable Statement in the scope-down statement, and you can nest statements at any level, the same as you can for a rule statement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
RuleGroupReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
OverrideAction
— required — (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
VisibilityConfig
— required — (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
ManagedByFirewallManager
— (Boolean
)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.
LabelNamespace
— (String
)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>
-
CustomResponseBodies
— (map<map>
)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.
ContentType
— required — (String
)The type of content in the payload that you are defining in the
Possible values include:Content
string."TEXT_PLAIN"
"TEXT_HTML"
"APPLICATION_JSON"
Content
— required — (String
)The payload of the custom response.
You can use JSON escape strings in JSON content. To do this, you must specify JSON content in the
ContentType
setting.For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations for rules that don't have their ownCaptchaConfig
settings. If you don't specify this, WAF uses its default settings forCaptchaConfig
.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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 forChallengeConfig
.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
TokenDomains
— (Array<String>
)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.
AssociationConfig
— (map
)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).
Note: 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).
RequestBody
— (map<map>
)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.
Note: 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).
DefaultSizeInspectionLimit
— required — (String
)Specifies the maximum size of the web request body component that an associated CloudFront, API Gateway, Amazon Cognito, App Runner, or Verified Access resource should send to WAF for inspection. This applies to statements in the web ACL that inspect the body or JSON body.
Default:
Possible values include:16 KB (16,384 bytes)
"KB_16"
"KB_32"
"KB_48"
"KB_64"
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ApplicationIntegrationURL
— (String
)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 groupAWSManagedRulesACFPRuleSet
. 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.
-
(AWS.Response)
—
Returns:
getWebACLForResource(params = {}, callback) ⇒ AWS.Request
Retrieves the WebACL for the specified resource.
This call uses
GetWebACL
, to verify that your account has permission to access the retrieved web ACL. If you get an error that indicates that your account isn't authorized to performwafv2:GetWebACL
on the resource, that error won't be included in your CloudTrail event history.For Amazon CloudFront, don't use this call. Instead, call the CloudFront action
GetDistributionConfig
. For information, see GetDistributionConfig in the Amazon CloudFront API Reference.Required permissions for customer-managed IAM policies
This call requires permissions that are specific to the protected resource type. For details, see Permissions for GetWebACLForResource in the WAF Developer Guide.
Service Reference:
Examples:
Calling the getWebACLForResource operation
var params = { ResourceArn: 'STRING_VALUE' /* required */ }; wafv2.getWebACLForResource(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
ResourceArn
— (String
)The Amazon Resource Name (ARN) of the resource whose web ACL you want to retrieve.
The ARN must be in one of the following formats:
-
For an Application Load Balancer:
arn:partition:elasticloadbalancing:region:account-id:loadbalancer/app/load-balancer-name/load-balancer-id
-
For an Amazon API Gateway REST API:
arn:partition:apigateway:region::/restapis/api-id/stages/stage-name
-
For an AppSync GraphQL API:
arn:partition:appsync:region:account-id:apis/GraphQLApiId
-
For an Amazon Cognito user pool:
arn:partition:cognito-idp:region:account-id:userpool/user-pool-id
-
For an App Runner service:
arn:partition:apprunner:region:account-id:service/apprunner-service-name/apprunner-service-id
-
For an Amazon Web Services Verified Access instance:
arn:partition:ec2:region:account-id:verified-access-instance/instance-id
-
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:WebACL
— (map
)The web ACL that is associated with the resource. If there is no associated resource, WAF returns a null web ACL.
Name
— required — (String
)The name of the web ACL. You cannot change the name of a web ACL after you create it.
Id
— required — (String
)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 aWebACL
.ARN
— required — (String
)The Amazon Resource Name (ARN) of the web ACL that you want to associate with the resource.
DefaultAction
— required — (map
)The action to perform if none of the
Rules
contained in theWebACL
match.Block
— (map
)Specifies that WAF should block requests by default.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Specifies that WAF should allow requests by default.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Description
— (String
)A description of the web ACL that helps with identification.
Rules
— (Array<map>
)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.
Name
— required — (String
)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'sVisibilityConfig
settings. WAF doesn't automatically update the metric name when you update the rule name.Priority
— required — (Integer
)If you define more than one
Rule
in aWebACL
, WAF evaluates each request against theRules
in order based on the value ofPriority
. WAF processes rules with lower priority first. The priorities don't need to be consecutive, but they must all be different.Statement
— required — (map
)The WAF processing statement for the rule, for example ByteMatchStatement or SizeConstraintStatement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.ManagedRuleGroupStatement
— (map
)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 aNotStatement
orOrStatement
. 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.Note: You are charged additional fees when you use the WAF Bot Control managed rule groupAWSManagedRulesBotControlRuleSet
, the WAF Fraud Control account takeover prevention (ATP) managed rule groupAWSManagedRulesATPRuleSet
, or the WAF Fraud Control account creation fraud prevention (ACFP) managed rule groupAWSManagedRulesACFPRuleSet
. For more information, see WAF Pricing.VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Action
— (map
)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
andManagedRuleGroupStatement
.You must specify either this
Action
setting or the ruleOverrideAction
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.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
-
OverrideAction
— (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
RuleLabels
— (Array<map>
)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
, oripset
.
For example,
myLabelName
ornameSpace1:nameSpace2:myLabelName
.Name
— required — (String
)The label string.
-
VisibilityConfig
— required — (map
)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.SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations. If you don't specify this, WAF uses theCAPTCHA
configuration that's defined for the web ACL.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
VisibilityConfig
— required — (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
Capacity
— (Integer
)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.
PreProcessFirewallManagerRuleGroups
— (Array<map>
)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.
Name
— required — (String
)The name of the rule group. You cannot change the name of a rule group after you create it.
Priority
— required — (Integer
)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.
FirewallManagerStatement
— required — (map
)The processing guidance for an Firewall Manager rule. This is like a regular rule Statement, but it can only contain a rule group reference.
ManagedRuleGroupStatement
— (map
)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.
VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ScopeDownStatement
— (map
)An optional nested statement that narrows the scope of the web requests that are evaluated by the managed rule group. Requests are only evaluated by the rule group if they match the scope-down statement. You can use any nestable Statement in the scope-down statement, and you can nest statements at any level, the same as you can for a rule statement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
RuleGroupReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
OverrideAction
— required — (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
VisibilityConfig
— required — (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
PostProcessFirewallManagerRuleGroups
— (Array<map>
)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.
Name
— required — (String
)The name of the rule group. You cannot change the name of a rule group after you create it.
Priority
— required — (Integer
)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.
FirewallManagerStatement
— required — (map
)The processing guidance for an Firewall Manager rule. This is like a regular rule Statement, but it can only contain a rule group reference.
ManagedRuleGroupStatement
— (map
)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.
VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ScopeDownStatement
— (map
)An optional nested statement that narrows the scope of the web requests that are evaluated by the managed rule group. Requests are only evaluated by the rule group if they match the scope-down statement. You can use any nestable Statement in the scope-down statement, and you can nest statements at any level, the same as you can for a rule statement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
RuleGroupReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
OverrideAction
— required — (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
VisibilityConfig
— required — (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
ManagedByFirewallManager
— (Boolean
)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.
LabelNamespace
— (String
)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>
-
CustomResponseBodies
— (map<map>
)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.
ContentType
— required — (String
)The type of content in the payload that you are defining in the
Possible values include:Content
string."TEXT_PLAIN"
"TEXT_HTML"
"APPLICATION_JSON"
Content
— required — (String
)The payload of the custom response.
You can use JSON escape strings in JSON content. To do this, you must specify JSON content in the
ContentType
setting.For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations for rules that don't have their ownCaptchaConfig
settings. If you don't specify this, WAF uses its default settings forCaptchaConfig
.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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 forChallengeConfig
.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
TokenDomains
— (Array<String>
)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.
AssociationConfig
— (map
)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).
Note: 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).
RequestBody
— (map<map>
)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.
Note: 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).
DefaultSizeInspectionLimit
— required — (String
)Specifies the maximum size of the web request body component that an associated CloudFront, API Gateway, Amazon Cognito, App Runner, or Verified Access resource should send to WAF for inspection. This applies to statements in the web ACL that inspect the body or JSON body.
Default:
Possible values include:16 KB (16,384 bytes)
"KB_16"
"KB_32"
"KB_48"
"KB_64"
-
(AWS.Response)
—
Returns:
listAPIKeys(params = {}, callback) ⇒ AWS.Request
Retrieves a list of the API keys that you've defined for the specified scope.
API keys are required for the integration of the CAPTCHA API in your JavaScript client applications. The API lets you customize the placement and characteristics of the CAPTCHA puzzle for your end users. For more information about the CAPTCHA JavaScript integration, see WAF client application integration in the WAF Developer Guide.
Service Reference:
Examples:
Calling the listAPIKeys operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listAPIKeys(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.APIKeySummaries
— (Array<map>
)The array of key summaries. If you specified a
Limit
in your request, this might not be the full list.TokenDomains
— (Array<String>
)The token domains that are defined in this API key.
APIKey
— (String
)The generated, encrypted API key. You can copy this for use in your JavaScript CAPTCHA integration.
CreationTimestamp
— (Date
)The date and time that the key was created.
Version
— (Integer
)Internal value used by WAF to manage the key.
ApplicationIntegrationURL
— (String
)The CAPTCHA application integration URL, for use in your JavaScript implementation.
-
(AWS.Response)
—
Returns:
listAvailableManagedRuleGroups(params = {}, callback) ⇒ AWS.Request
Retrieves an array of managed rule groups that are available for you to use. This list includes all Amazon Web Services Managed Rules rule groups and all of the Amazon Web Services Marketplace managed rule groups that you're subscribed to.
Service Reference:
Examples:
Calling the listAvailableManagedRuleGroups operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listAvailableManagedRuleGroups(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.ManagedRuleGroups
— (Array<map>
)Array of managed rule groups that you can use. If you specified a
Limit
in your request, this might not be the full list.VendorName
— (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
VersioningSupported
— (Boolean
)Indicates whether the managed rule group is versioned. If it is, you can retrieve the versions list by calling ListAvailableManagedRuleGroupVersions.
Description
— (String
)The description of the managed rule group, provided by Amazon Web Services Managed Rules or the Amazon Web Services Marketplace seller who manages it.
-
(AWS.Response)
—
Returns:
listAvailableManagedRuleGroupVersions(params = {}, callback) ⇒ AWS.Request
Returns a list of the available versions for the specified managed rule group.
Service Reference:
Examples:
Calling the listAvailableManagedRuleGroupVersions operation
var params = { Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ VendorName: 'STRING_VALUE', /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listAvailableManagedRuleGroupVersions(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
VendorName
— (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Versions
— (Array<map>
)The versions that are currently available for the specified managed rule group. If you specified a
Limit
in your request, this might not be the full list.Name
— (String
)The version name.
LastUpdateTimestamp
— (Date
)The date and time that the managed rule group owner updated the rule group version information.
CurrentDefaultVersion
— (String
)The name of the version that's currently set as the default.
-
(AWS.Response)
—
Returns:
listIPSets(params = {}, callback) ⇒ AWS.Request
Retrieves an array of IPSetSummary objects for the IP sets that you manage.
Service Reference:
Examples:
Calling the listIPSets operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listIPSets(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.IPSets
— (Array<map>
)Array of IPSets. If you specified a
Limit
in your request, this might not be the full list.Name
— (String
)The name of the IP set. You cannot change the name of an
IPSet
after you create it.Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Description
— (String
)A description of the IP set that helps with identification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
-
(AWS.Response)
—
Returns:
listLoggingConfigurations(params = {}, callback) ⇒ AWS.Request
Retrieves an array of your LoggingConfiguration objects.
Service Reference:
Examples:
Calling the listLoggingConfigurations operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ Limit: 'NUMBER_VALUE', LogScope: CUSTOMER | SECURITY_LAKE, NextMarker: 'STRING_VALUE' }; wafv2.listLoggingConfigurations(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.LogScope
— (String
)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:
Possible values include:CUSTOMER
"CUSTOMER"
"SECURITY_LAKE"
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:LoggingConfigurations
— (Array<map>
)Array of logging configurations. If you specified a
Limit
in your request, this might not be the full list.ResourceArn
— required — (String
)The Amazon Resource Name (ARN) of the web ACL that you want to associate with
LogDestinationConfigs
.LogDestinationConfigs
— required — (Array<String>
)The logging destination configuration that you want to associate with the web ACL.
Note: You can associate one logging destination to a web ACL.RedactedFields
— (Array<map>
)The parts of the request that you want to keep out of the logs.
For example, if you redact the
SingleHeader
field, theHEADER
field in the logs will beREDACTED
for all rules that use theSingleHeader
FieldToMatch
setting.Redaction applies only to the component that's specified in the rule's
FieldToMatch
setting, so theSingleHeader
redaction doesn't apply to rules that use theHeaders
FieldToMatch
.Note: You can specify only the following fields for redaction:UriPath
,QueryString
,SingleHeader
, andMethod
.Note: 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.SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ManagedByFirewallManager
— (Boolean
)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.
LoggingFilter
— (map
)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.
Filters
— required — (Array<map>
)The filters that you want to apply to the logs.
Behavior
— required — (String
)How to handle logs that satisfy the filter's conditions and requirement.
Possible values include:"KEEP"
"DROP"
Requirement
— required — (String
)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.
Possible values include:"MEETS_ALL"
"MEETS_ANY"
Conditions
— required — (Array<map>
)Match conditions for the filter.
ActionCondition
— (map
)A single action condition. This is the action setting that a log record must contain in order to meet the condition.
Action
— required — (String
)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
Possible values include:EXCLUDED_AS_COUNT
matches on excluded rules and also on rules that have a rule action override of Count."ALLOW"
"BLOCK"
"COUNT"
"CAPTCHA"
"CHALLENGE"
"EXCLUDED_AS_COUNT"
LabelNameCondition
— (map
)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.
LabelName
— required — (String
)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.
DefaultBehavior
— required — (String
)Default handling for logs that don't match any of the specified filtering conditions.
Possible values include:"KEEP"
"DROP"
LogType
— (String
)Used to distinguish between various logging options. Currently, there is one option.
Default:
Possible values include:WAF_LOGS
"WAF_LOGS"
LogScope
— (String
)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:
Possible values include:CUSTOMER
"CUSTOMER"
"SECURITY_LAKE"
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.
-
(AWS.Response)
—
Returns:
listManagedRuleSets(params = {}, callback) ⇒ AWS.Request
Retrieves the managed rule sets that you own.
Note: This is intended for use only by vendors of managed rule sets. Vendors are Amazon Web Services and Amazon Web Services Marketplace sellers. Vendors, you can use the managed rule set APIs to provide controlled rollout of your versioned managed rule group offerings for your customers. The APIs areListManagedRuleSets
,GetManagedRuleSet
,PutManagedRuleSetVersions
, andUpdateManagedRuleSetVersionExpiryDate
.Service Reference:
Examples:
Calling the listManagedRuleSets operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listManagedRuleSets(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.ManagedRuleSets
— (Array<map>
)Your managed rule sets. If you specified a
Limit
in your request, this might not be the full list.Name
— (String
)The name of the managed rule set. You use this, along with the rule set ID, to identify the rule set.
This name is assigned to the corresponding managed rule group, which your customers can access and use.
Id
— (String
)A unique identifier for the managed rule set. The ID is returned in the responses to commands like
list
. You provide it to operations likeget
andupdate
.Description
— (String
)A description of the set that helps with identification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
LabelNamespace
— (String
)The label namespace prefix for the managed rule groups that are offered to customers from this managed rule set. All labels that are added by rules in the managed rule group have this prefix.
-
The syntax for the label namespace prefix for a managed rule group is the following:
awswaf:managed:<vendor>:<rule group 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>
-
-
(AWS.Response)
—
Returns:
listMobileSdkReleases(params = {}, callback) ⇒ AWS.Request
Retrieves a list of the available releases for the mobile SDK and the specified device platform.
The mobile SDK is not generally available. Customers who have access to the mobile SDK can use it to establish and manage WAF tokens for use in HTTP(S) requests from a mobile device to WAF. For more information, see WAF client application integration in the WAF Developer Guide.
Service Reference:
Examples:
Calling the listMobileSdkReleases operation
var params = { Platform: IOS | ANDROID, /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listMobileSdkReleases(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Platform
— (String
)The device platform to retrieve the list for.
Possible values include:"IOS"
"ANDROID"
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:ReleaseSummaries
— (Array<map>
)The high level information for the available SDK releases. If you specified a
Limit
in your request, this might not be the full list.ReleaseVersion
— (String
)The release version.
Timestamp
— (Date
)The timestamp of the release.
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.
-
(AWS.Response)
—
Returns:
listRegexPatternSets(params = {}, callback) ⇒ AWS.Request
Retrieves an array of RegexPatternSetSummary objects for the regex pattern sets that you manage.
Service Reference:
Examples:
Calling the listRegexPatternSets operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listRegexPatternSets(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.RegexPatternSets
— (Array<map>
)Array of regex pattern sets. If you specified a
Limit
in your request, this might not be the full list.Name
— (String
)The name of the data type instance. You cannot change the name after you create the instance.
Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Description
— (String
)A description of the set that helps with identification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
-
(AWS.Response)
—
Returns:
listResourcesForWebACL(params = {}, callback) ⇒ AWS.Request
Retrieves an array of the Amazon Resource Names (ARNs) for the regional resources that are associated with the specified web ACL.
For Amazon CloudFront, don't use this call. Instead, use the CloudFront call
ListDistributionsByWebACLId
. For information, see ListDistributionsByWebACLId in the Amazon CloudFront API Reference.Required permissions for customer-managed IAM policies
This call requires permissions that are specific to the protected resource type. For details, see Permissions for ListResourcesForWebACL in the WAF Developer Guide.
Service Reference:
Examples:
Calling the listResourcesForWebACL operation
var params = { WebACLArn: 'STRING_VALUE', /* required */ ResourceType: APPLICATION_LOAD_BALANCER | API_GATEWAY | APPSYNC | COGNITO_USER_POOL | APP_RUNNER_SERVICE | VERIFIED_ACCESS_INSTANCE }; wafv2.listResourcesForWebACL(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
WebACLArn
— (String
)The Amazon Resource Name (ARN) of the web ACL.
ResourceType
— (String
)Used for web ACLs that are scoped for regional applications. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
Note: If you don't provide a resource type, the call uses the resource typeAPPLICATION_LOAD_BALANCER
.Default:
Possible values include:APPLICATION_LOAD_BALANCER
"APPLICATION_LOAD_BALANCER"
"API_GATEWAY"
"APPSYNC"
"COGNITO_USER_POOL"
"APP_RUNNER_SERVICE"
"VERIFIED_ACCESS_INSTANCE"
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:ResourceArns
— (Array<String>
)The array of Amazon Resource Names (ARNs) of the associated resources.
-
(AWS.Response)
—
Returns:
listRuleGroups(params = {}, callback) ⇒ AWS.Request
Retrieves an array of RuleGroupSummary objects for the rule groups that you manage.
Service Reference:
Examples:
Calling the listRuleGroups operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listRuleGroups(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.RuleGroups
— (Array<map>
)Array of rule groups. If you specified a
Limit
in your request, this might not be the full list.Name
— (String
)The name of the data type instance. You cannot change the name after you create the instance.
Id
— (String
)A unique identifier for the rule group. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Description
— (String
)A description of the rule group that helps with identification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
-
(AWS.Response)
—
Returns:
listTagsForResource(params = {}, callback) ⇒ AWS.Request
Retrieves the TagInfoForResource for the specified resource. Tags are key:value pairs that you can use to categorize and manage your resources, for purposes like billing. For example, you might set the tag key to "customer" and the value to the customer name or ID. You can specify one or more tags to add to each Amazon Web Services resource, up to 50 tags for a resource.
You can tag the Amazon Web Services resources that you manage through WAF: web ACLs, rule groups, IP sets, and regex pattern sets. You can't manage or view tags through the WAF console.
Service Reference:
Examples:
Calling the listTagsForResource operation
var params = { ResourceARN: 'STRING_VALUE', /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listTagsForResource(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.ResourceARN
— (String
)The Amazon Resource Name (ARN) of the resource.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.TagInfoForResource
— (map
)The collection of tagging definitions for the resource. If you specified a
Limit
in your request, this might not be the full list.ResourceARN
— (String
)The Amazon Resource Name (ARN) of the resource.
TagList
— (Array<map>
)The array of Tag objects defined for the resource.
Key
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag key to describe a category of information, such as "customer." Tag keys are case-sensitive.
Value
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag value to describe a specific value within a category, such as "companyA" or "companyB." Tag values are case-sensitive.
-
(AWS.Response)
—
Returns:
listWebACLs(params = {}, callback) ⇒ AWS.Request
Retrieves an array of WebACLSummary objects for the web ACLs that you manage.
Service Reference:
Examples:
Calling the listWebACLs operation
var params = { Scope: CLOUDFRONT | REGIONAL, /* required */ Limit: 'NUMBER_VALUE', NextMarker: 'STRING_VALUE' }; wafv2.listWebACLs(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.Limit
— (Integer
)The maximum number of objects that you want WAF to return for this request. If more objects are available, in the response, WAF provides a
NextMarker
value that you can use in a subsequent call to get the next batch of objects.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextMarker
— (String
)When you request a list of objects with a
Limit
setting, if the number of objects that are still available for retrieval exceeds the limit, WAF returns aNextMarker
value in the response. To retrieve the next batch of objects, provide the marker from the prior call in your next request.WebACLs
— (Array<map>
)Array of web ACLs. If you specified a
Limit
in your request, this might not be the full list.Name
— (String
)The name of the web ACL. You cannot change the name of a web ACL after you create it.
Id
— (String
)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.
Description
— (String
)A description of the web ACL that helps with identification.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.ARN
— (String
)The Amazon Resource Name (ARN) of the entity.
-
(AWS.Response)
—
Returns:
putLoggingConfiguration(params = {}, callback) ⇒ AWS.Request
Enables the specified LoggingConfiguration, to start logging from a web ACL, according to the configuration provided.
Note: This operation completely replaces any mutable specifications that you already have for a logging configuration with the ones that you provide to this call. To modify an existing logging configuration, do the following:- Retrieve it by calling GetLoggingConfiguration
- Update its settings as needed
- Provide the complete logging configuration specification to this call
Note: You can define one logging destination per web ACL.You can access information about the traffic that WAF inspects using the following steps:
-
Create your logging destination. You can use an Amazon CloudWatch Logs log group, an Amazon Simple Storage Service (Amazon S3) bucket, or an Amazon Kinesis Data Firehose.
The name that you give the destination must start with
aws-waf-logs-
. Depending on the type of destination, you might need to configure additional settings or permissions.For configuration requirements and pricing information for each destination type, see Logging web ACL traffic in the WAF Developer Guide.
-
Associate your logging destination to your web ACL using a
PutLoggingConfiguration
request.
When you successfully enable logging using a
PutLoggingConfiguration
request, WAF creates an additional role or policy that is required to write logs to the logging destination. For an Amazon CloudWatch Logs log group, WAF creates a resource policy on the log group. For an Amazon S3 bucket, WAF creates a bucket policy. For an Amazon Kinesis Data Firehose, WAF creates a service-linked role.For additional information about web ACL logging, see Logging web ACL traffic information in the WAF Developer Guide.
Service Reference:
Examples:
Calling the putLoggingConfiguration operation
var params = { LoggingConfiguration: { /* required */ LogDestinationConfigs: [ /* required */ 'STRING_VALUE', /* more items */ ], ResourceArn: 'STRING_VALUE', /* required */ LogScope: CUSTOMER | SECURITY_LAKE, LogType: WAF_LOGS, LoggingFilter: { DefaultBehavior: KEEP | DROP, /* required */ Filters: [ /* required */ { Behavior: KEEP | DROP, /* required */ Conditions: [ /* required */ { ActionCondition: { Action: ALLOW | BLOCK | COUNT | CAPTCHA | CHALLENGE | EXCLUDED_AS_COUNT /* required */ }, LabelNameCondition: { LabelName: 'STRING_VALUE' /* required */ } }, /* more items */ ], Requirement: MEETS_ALL | MEETS_ANY /* required */ }, /* more items */ ] }, ManagedByFirewallManager: true || false, RedactedFields: [ { AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, /* more items */ ] } }; wafv2.putLoggingConfiguration(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
LoggingConfiguration
— (map
)ResourceArn
— required — (String
)The Amazon Resource Name (ARN) of the web ACL that you want to associate with
LogDestinationConfigs
.LogDestinationConfigs
— required — (Array<String>
)The logging destination configuration that you want to associate with the web ACL.
Note: You can associate one logging destination to a web ACL.RedactedFields
— (Array<map>
)The parts of the request that you want to keep out of the logs.
For example, if you redact the
SingleHeader
field, theHEADER
field in the logs will beREDACTED
for all rules that use theSingleHeader
FieldToMatch
setting.Redaction applies only to the component that's specified in the rule's
FieldToMatch
setting, so theSingleHeader
redaction doesn't apply to rules that use theHeaders
FieldToMatch
.Note: You can specify only the following fields for redaction:UriPath
,QueryString
,SingleHeader
, andMethod
.Note: 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.SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ManagedByFirewallManager
— (Boolean
)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.
LoggingFilter
— (map
)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.
Filters
— required — (Array<map>
)The filters that you want to apply to the logs.
Behavior
— required — (String
)How to handle logs that satisfy the filter's conditions and requirement.
Possible values include:"KEEP"
"DROP"
Requirement
— required — (String
)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.
Possible values include:"MEETS_ALL"
"MEETS_ANY"
Conditions
— required — (Array<map>
)Match conditions for the filter.
ActionCondition
— (map
)A single action condition. This is the action setting that a log record must contain in order to meet the condition.
Action
— required — (String
)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
Possible values include:EXCLUDED_AS_COUNT
matches on excluded rules and also on rules that have a rule action override of Count."ALLOW"
"BLOCK"
"COUNT"
"CAPTCHA"
"CHALLENGE"
"EXCLUDED_AS_COUNT"
LabelNameCondition
— (map
)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.
LabelName
— required — (String
)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.
DefaultBehavior
— required — (String
)Default handling for logs that don't match any of the specified filtering conditions.
Possible values include:"KEEP"
"DROP"
LogType
— (String
)Used to distinguish between various logging options. Currently, there is one option.
Default:
Possible values include:WAF_LOGS
"WAF_LOGS"
LogScope
— (String
)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:
Possible values include:CUSTOMER
"CUSTOMER"
"SECURITY_LAKE"
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:LoggingConfiguration
— (map
)ResourceArn
— required — (String
)The Amazon Resource Name (ARN) of the web ACL that you want to associate with
LogDestinationConfigs
.LogDestinationConfigs
— required — (Array<String>
)The logging destination configuration that you want to associate with the web ACL.
Note: You can associate one logging destination to a web ACL.RedactedFields
— (Array<map>
)The parts of the request that you want to keep out of the logs.
For example, if you redact the
SingleHeader
field, theHEADER
field in the logs will beREDACTED
for all rules that use theSingleHeader
FieldToMatch
setting.Redaction applies only to the component that's specified in the rule's
FieldToMatch
setting, so theSingleHeader
redaction doesn't apply to rules that use theHeaders
FieldToMatch
.Note: You can specify only the following fields for redaction:UriPath
,QueryString
,SingleHeader
, andMethod
.Note: 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.SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ManagedByFirewallManager
— (Boolean
)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.
LoggingFilter
— (map
)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.
Filters
— required — (Array<map>
)The filters that you want to apply to the logs.
Behavior
— required — (String
)How to handle logs that satisfy the filter's conditions and requirement.
Possible values include:"KEEP"
"DROP"
Requirement
— required — (String
)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.
Possible values include:"MEETS_ALL"
"MEETS_ANY"
Conditions
— required — (Array<map>
)Match conditions for the filter.
ActionCondition
— (map
)A single action condition. This is the action setting that a log record must contain in order to meet the condition.
Action
— required — (String
)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
Possible values include:EXCLUDED_AS_COUNT
matches on excluded rules and also on rules that have a rule action override of Count."ALLOW"
"BLOCK"
"COUNT"
"CAPTCHA"
"CHALLENGE"
"EXCLUDED_AS_COUNT"
LabelNameCondition
— (map
)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.
LabelName
— required — (String
)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.
DefaultBehavior
— required — (String
)Default handling for logs that don't match any of the specified filtering conditions.
Possible values include:"KEEP"
"DROP"
LogType
— (String
)Used to distinguish between various logging options. Currently, there is one option.
Default:
Possible values include:WAF_LOGS
"WAF_LOGS"
LogScope
— (String
)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:
Possible values include:CUSTOMER
"CUSTOMER"
"SECURITY_LAKE"
-
(AWS.Response)
—
Returns:
putManagedRuleSetVersions(params = {}, callback) ⇒ AWS.Request
Defines the versions of your managed rule set that you are offering to the customers. Customers see your offerings as managed rule groups with versioning.
Note: This is intended for use only by vendors of managed rule sets. Vendors are Amazon Web Services and Amazon Web Services Marketplace sellers. Vendors, you can use the managed rule set APIs to provide controlled rollout of your versioned managed rule group offerings for your customers. The APIs areListManagedRuleSets
,GetManagedRuleSet
,PutManagedRuleSetVersions
, andUpdateManagedRuleSetVersionExpiryDate
.Customers retrieve their managed rule group list by calling ListAvailableManagedRuleGroups. The name that you provide here for your managed rule set is the name the customer sees for the corresponding managed rule group. Customers can retrieve the available versions for a managed rule group by calling ListAvailableManagedRuleGroupVersions. You provide a rule group specification for each version. For each managed rule set, you must specify a version that you recommend using.
To initiate the expiration of a managed rule group version, use UpdateManagedRuleSetVersionExpiryDate.
Service Reference:
Examples:
Calling the putManagedRuleSetVersions operation
var params = { Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ RecommendedVersion: 'STRING_VALUE', VersionsToPublish: { '<VersionKeyString>': { AssociatedRuleGroupArn: 'STRING_VALUE', ForecastedLifetime: 'NUMBER_VALUE' }, /* '<VersionKeyString>': ... */ } }; wafv2.putManagedRuleSetVersions(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the managed rule set. You use this, along with the rule set ID, to identify the rule set.
This name is assigned to the corresponding managed rule group, which your customers can access and use.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the managed rule set. The ID is returned in the responses to commands like
list
. You provide it to operations likeget
andupdate
.LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.RecommendedVersion
— (String
)The version of the named managed rule group that you'd like your customers to choose, from among your version offerings.
VersionsToPublish
— (map<map>
)The versions of the named managed rule group that you want to offer to your customers.
AssociatedRuleGroupArn
— (String
)The Amazon Resource Name (ARN) of the vendor's rule group that's used in the published managed rule group version.
ForecastedLifetime
— (Integer
)The amount of time the vendor expects this version of the managed rule group to last, in days.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextLockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
-
(AWS.Response)
—
Returns:
putPermissionPolicy(params = {}, callback) ⇒ AWS.Request
Use this to share a rule group with other accounts.
This action attaches an IAM policy to the specified resource. You must be the owner of the rule group to perform this operation.
This action is subject to the following restrictions:
-
You can attach only one policy with each
PutPermissionPolicy
request. -
The ARN in the request must be a valid WAF RuleGroup ARN and the rule group must exist in the same Region.
-
The user making the request must be the owner of the rule group.
If a rule group has been shared with your account, you can access it through the call
GetRuleGroup
, and you can reference it inCreateWebACL
andUpdateWebACL
. Rule groups that are shared with you don't appear in your WAF console rule groups listing.Service Reference:
Examples:
Calling the putPermissionPolicy operation
var params = { Policy: 'STRING_VALUE', /* required */ ResourceArn: 'STRING_VALUE' /* required */ }; wafv2.putPermissionPolicy(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
ResourceArn
— (String
)The Amazon Resource Name (ARN) of the RuleGroup to which you want to attach the policy.
Policy
— (String
)The policy to attach to the specified rule group.
The policy specifications must conform to the following:
-
The policy must be composed using IAM Policy version 2012-10-17.
-
The policy must include specifications for
Effect
,Action
, andPrincipal
. -
Effect
must specifyAllow
. -
Action
must specifywafv2:CreateWebACL
,wafv2:UpdateWebACL
, andwafv2:PutFirewallManagerRuleGroups
and may optionally specifywafv2:GetRuleGroup
. WAF rejects any extra actions or wildcard actions in the policy. -
The policy must not include a
Resource
parameter.
For more information, see IAM Policies.
-
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
tagResource(params = {}, callback) ⇒ AWS.Request
Associates tags with the specified Amazon Web Services resource. Tags are key:value pairs that you can use to categorize and manage your resources, for purposes like billing. For example, you might set the tag key to "customer" and the value to the customer name or ID. You can specify one or more tags to add to each Amazon Web Services resource, up to 50 tags for a resource.
You can tag the Amazon Web Services resources that you manage through WAF: web ACLs, rule groups, IP sets, and regex pattern sets. You can't manage or view tags through the WAF console.
Service Reference:
Examples:
Calling the tagResource operation
var params = { ResourceARN: 'STRING_VALUE', /* required */ Tags: [ /* required */ { Key: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] }; wafv2.tagResource(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
ResourceARN
— (String
)The Amazon Resource Name (ARN) of the resource.
Tags
— (Array<map>
)An array of key:value pairs to associate with the resource.
Key
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag key to describe a category of information, such as "customer." Tag keys are case-sensitive.
Value
— required — (String
)Part of the key:value pair that defines a tag. You can use a tag value to describe a specific value within a category, such as "companyA" or "companyB." Tag values are case-sensitive.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
untagResource(params = {}, callback) ⇒ AWS.Request
Disassociates tags from an Amazon Web Services resource. Tags are key:value pairs that you can associate with Amazon Web Services resources. For example, the tag key might be "customer" and the tag value might be "companyA." You can specify one or more tags to add to each container. You can add up to 50 tags to each Amazon Web Services resource.
Service Reference:
Examples:
Calling the untagResource operation
var params = { ResourceARN: 'STRING_VALUE', /* required */ TagKeys: [ /* required */ 'STRING_VALUE', /* more items */ ] }; wafv2.untagResource(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
ResourceARN
— (String
)The Amazon Resource Name (ARN) of the resource.
TagKeys
— (Array<String>
)An array of keys identifying the tags to disassociate from the resource.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs.
-
(AWS.Response)
—
Returns:
updateIPSet(params = {}, callback) ⇒ AWS.Request
Updates the specified IPSet.
Note: This operation completely replaces the mutable specifications that you already have for the IP set with the ones that you provide to this call. To modify an IP set, do the following:- Retrieve it by calling GetIPSet
- Update its settings as needed
- Provide the complete IP set specification to this call
Temporary inconsistencies during updates
When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
The following are examples of the temporary inconsistencies that you might notice during change propagation:
-
After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
-
After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
-
After you change a rule action setting, you might see the old action in some places and the new action in others.
-
After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
Service Reference:
Examples:
Calling the updateIPSet operation
var params = { Addresses: [ /* required */ 'STRING_VALUE', /* more items */ ], Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ Description: 'STRING_VALUE' }; wafv2.updateIPSet(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the IP set. You cannot change the name of an
IPSet
after you create it.Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Description
— (String
)A description of the IP set that helps with identification.
Addresses
— (Array<String>
)Contains an array of strings that specifies zero or more IP addresses or blocks of IP addresses that you want WAF to inspect for in incoming requests. All addresses must be specified using Classless Inter-Domain Routing (CIDR) notation. WAF supports all IPv4 and IPv6 CIDR ranges except for
/0
.Example address strings:
-
For requests that originated from the IP address 192.0.2.44, specify
192.0.2.44/32
. -
For requests that originated from IP addresses from 192.0.2.0 to 192.0.2.255, specify
192.0.2.0/24
. -
For requests that originated from the IP address 1111:0000:0000:0000:0000:0000:0000:0111, specify
1111:0000:0000:0000:0000:0000:0000:0111/128
. -
For requests that originated from IP addresses 1111:0000:0000:0000:0000:0000:0000:0000 to 1111:0000:0000:0000:ffff:ffff:ffff:ffff, specify
1111:0000:0000:0000:0000:0000:0000:0000/64
.
For more information about CIDR notation, see the Wikipedia entry Classless Inter-Domain Routing.
Example JSON
Addresses
specifications:-
Empty array:
"Addresses": []
-
Array with one address:
"Addresses": ["192.0.2.44/32"]
-
Array with three addresses:
"Addresses": ["192.0.2.44/32", "192.0.2.0/24", "192.0.0.0/16"]
-
INVALID specification:
"Addresses": [""]
INVALID
-
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextLockToken
— (String
)A token used for optimistic locking. WAF returns this token to your
update
requests. You useNextLockToken
in the same manner as you useLockToken
.
-
(AWS.Response)
—
Returns:
updateManagedRuleSetVersionExpiryDate(params = {}, callback) ⇒ AWS.Request
Updates the expiration information for your managed rule set. Use this to initiate the expiration of a managed rule group version. After you initiate expiration for a version, WAF excludes it from the response to ListAvailableManagedRuleGroupVersions for the managed rule group.
Note: This is intended for use only by vendors of managed rule sets. Vendors are Amazon Web Services and Amazon Web Services Marketplace sellers. Vendors, you can use the managed rule set APIs to provide controlled rollout of your versioned managed rule group offerings for your customers. The APIs areListManagedRuleSets
,GetManagedRuleSet
,PutManagedRuleSetVersions
, andUpdateManagedRuleSetVersionExpiryDate
.Service Reference:
Examples:
Calling the updateManagedRuleSetVersionExpiryDate operation
var params = { ExpiryTimestamp: new Date || 'Wed Dec 31 1969 16:00:00 GMT-0800 (PST)' || 123456789, /* required */ Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ VersionToExpire: 'STRING_VALUE' /* required */ }; wafv2.updateManagedRuleSetVersionExpiryDate(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the managed rule set. You use this, along with the rule set ID, to identify the rule set.
This name is assigned to the corresponding managed rule group, which your customers can access and use.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the managed rule set. The ID is returned in the responses to commands like
list
. You provide it to operations likeget
andupdate
.LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.VersionToExpire
— (String
)The version that you want to remove from your list of offerings for the named managed rule group.
ExpiryTimestamp
— (Date
)The time that you want the version to expire.
Times are in Coordinated Universal Time (UTC) format. UTC format includes the special designator, Z. For example, "2016-09-27T14:50Z".
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:ExpiringVersion
— (String
)The version that is set to expire.
ExpiryTimestamp
— (Date
)The time that the version will expire.
Times are in Coordinated Universal Time (UTC) format. UTC format includes the special designator, Z. For example, "2016-09-27T14:50Z".
NextLockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
-
(AWS.Response)
—
Returns:
updateRegexPatternSet(params = {}, callback) ⇒ AWS.Request
Updates the specified RegexPatternSet.
Note: This operation completely replaces the mutable specifications that you already have for the regex pattern set with the ones that you provide to this call. To modify a regex pattern set, do the following:- Retrieve it by calling GetRegexPatternSet
- Update its settings as needed
- Provide the complete regex pattern set specification to this call
Temporary inconsistencies during updates
When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
The following are examples of the temporary inconsistencies that you might notice during change propagation:
-
After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
-
After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
-
After you change a rule action setting, you might see the old action in some places and the new action in others.
-
After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
Service Reference:
Examples:
Calling the updateRegexPatternSet operation
var params = { Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ RegularExpressionList: [ /* required */ { RegexString: 'STRING_VALUE' }, /* more items */ ], Scope: CLOUDFRONT | REGIONAL, /* required */ Description: 'STRING_VALUE' }; wafv2.updateRegexPatternSet(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the set. You cannot change the name after you create the set.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the set. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Description
— (String
)A description of the set that helps with identification.
RegularExpressionList
— (Array<map>
)RegexString
— (String
)The string representing the regular expression.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextLockToken
— (String
)A token used for optimistic locking. WAF returns this token to your
update
requests. You useNextLockToken
in the same manner as you useLockToken
.
-
(AWS.Response)
—
Returns:
updateRuleGroup(params = {}, callback) ⇒ AWS.Request
Updates the specified RuleGroup.
Note: This operation completely replaces the mutable specifications that you already have for the rule group with the ones that you provide to this call. To modify a rule group, do the following:- Retrieve it by calling GetRuleGroup
- Update its settings as needed
- Provide the complete rule group specification to this call
A rule group defines a collection of rules to inspect and control web requests that you can use in a WebACL. When you create a rule group, you define an immutable capacity limit. If you update a rule group, you must stay within the capacity. This allows others to reuse the rule group with confidence in its capacity requirements.
Temporary inconsistencies during updates
When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
The following are examples of the temporary inconsistencies that you might notice during change propagation:
-
After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
-
After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
-
After you change a rule action setting, you might see the old action in some places and the new action in others.
-
After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
Service Reference:
Examples:
Calling the updateRuleGroup operation
var params = { Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ VisibilityConfig: { /* required */ CloudWatchMetricsEnabled: true || false, /* required */ MetricName: 'STRING_VALUE', /* required */ SampledRequestsEnabled: true || false /* required */ }, CustomResponseBodies: { '<EntityName>': { Content: 'STRING_VALUE', /* required */ ContentType: TEXT_PLAIN | TEXT_HTML | APPLICATION_JSON /* required */ }, /* '<EntityName>': ... */ }, Description: 'STRING_VALUE', Rules: [ { Name: 'STRING_VALUE', /* required */ Priority: 'NUMBER_VALUE', /* required */ Statement: { /* Statement */ /* required */ AndStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, ByteMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, PositionalConstraint: EXACTLY | STARTS_WITH | ENDS_WITH | CONTAINS | CONTAINS_WORD, /* required */ SearchString: Buffer.from('...') || 'STRING_VALUE' /* Strings will be Base-64 encoded on your behalf */, /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, GeoMatchStatement: { CountryCodes: [ AF | AX | AL | DZ | AS | AD | AO | AI | AQ | AG | AR | AM | AW | AU | AT | AZ | BS | BH | BD | BB | BY | BE | BZ | BJ | BM | BT | BO | BQ | BA | BW | BV | BR | IO | BN | BG | BF | BI | KH | CM | CA | CV | KY | CF | TD | CL | CN | CX | CC | CO | KM | CG | CD | CK | CR | CI | HR | CU | CW | CY | CZ | DK | DJ | DM | DO | EC | EG | SV | GQ | ER | EE | ET | FK | FO | FJ | FI | FR | GF | PF | TF | GA | GM | GE | DE | GH | GI | GR | GL | GD | GP | GU | GT | GG | GN | GW | GY | HT | HM | VA | HN | HK | HU | IS | IN | ID | IR | IQ | IE | IM | IL | IT | JM | JP | JE | JO | KZ | KE | KI | KP | KR | KW | KG | LA | LV | LB | LS | LR | LY | LI | LT | LU | MO | MK | MG | MW | MY | MV | ML | MT | MH | MQ | MR | MU | YT | MX | FM | MD | MC | MN | ME | MS | MA | MZ | MM | NA | NR | NP | NL | NC | NZ | NI | NE | NG | NU | NF | MP | NO | OM | PK | PW | PS | PA | PG | PY | PE | PH | PN | PL | PT | PR | QA | RE | RO | RU | RW | BL | SH | KN | LC | MF | PM | VC | WS | SM | ST | SA | SN | RS | SC | SL | SG | SX | SK | SI | SB | SO | ZA | GS | SS | ES | LK | SD | SR | SJ | SZ | SE | CH | SY | TW | TJ | TZ | TH | TL | TG | TK | TO | TT | TN | TR | TM | TC | TV | UG | UA | AE | GB | US | UM | UY | UZ | VU | VE | VN | VG | VI | WF | EH | YE | ZM | ZW | XK, /* more items */ ], ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ } }, IPSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ IPSetForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE', /* required */ Position: FIRST | LAST | ANY /* required */ } }, LabelMatchStatement: { Key: 'STRING_VALUE', /* required */ Scope: LABEL | NAMESPACE /* required */ }, ManagedRuleGroupStatement: { Name: 'STRING_VALUE', /* required */ VendorName: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ManagedRuleGroupConfigs: [ { AWSManagedRulesACFPRuleSet: { CreationPath: 'STRING_VALUE', /* required */ RegistrationPagePath: 'STRING_VALUE', /* required */ RequestInspection: { /* required */ PayloadType: JSON | FORM_ENCODED, /* required */ AddressFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], EmailField: { Identifier: 'STRING_VALUE' /* required */ }, PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PhoneNumberFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, EnableRegexInPath: true || false, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesATPRuleSet: { LoginPath: 'STRING_VALUE', /* required */ EnableRegexInPath: true || false, RequestInspection: { PasswordField: { /* required */ Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, /* required */ UsernameField: { /* required */ Identifier: 'STRING_VALUE' /* required */ } }, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesBotControlRuleSet: { InspectionLevel: COMMON | TARGETED, /* required */ EnableMachineLearning: true || false }, LoginPath: 'STRING_VALUE', PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ScopeDownStatement: /* recursive Statement */, Version: 'STRING_VALUE' }, NotStatement: { Statement: /* recursive Statement */ }, OrStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, RateBasedStatement: { AggregateKeyType: IP | FORWARDED_IP | CUSTOM_KEYS | CONSTANT, /* required */ Limit: 'NUMBER_VALUE', /* required */ CustomKeys: [ { Cookie: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, ForwardedIP: { }, HTTPMethod: { }, Header: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, IP: { }, LabelNamespace: { Namespace: 'STRING_VALUE' /* required */ }, QueryArgument: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, QueryString: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, UriPath: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, /* more items */ ], EvaluationWindowSec: 'NUMBER_VALUE', ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ }, ScopeDownStatement: /* recursive Statement */ }, RegexMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, RegexString: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RegexPatternSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RuleGroupReferenceStatement: { ARN: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, SizeConstraintStatement: { ComparisonOperator: EQ | NE | LE | LT | GE | GT, /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, Size: 'NUMBER_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, SqliMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ], SensitivityLevel: LOW | HIGH }, XssMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, VisibilityConfig: { /* required */ CloudWatchMetricsEnabled: true || false, /* required */ MetricName: 'STRING_VALUE', /* required */ SampledRequestsEnabled: true || false /* required */ }, Action: { Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, CaptchaConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, ChallengeConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, OverrideAction: { Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, None: { } }, RuleLabels: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, /* more items */ ] }; wafv2.updateRuleGroup(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the rule group. You cannot change the name of a rule group after you create it.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)A unique identifier for the rule group. This ID is returned in the responses to create and list commands. You provide it to operations like update and delete.
Description
— (String
)A description of the rule group that helps with identification.
Rules
— (Array<map>
)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.
Name
— required — (String
)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'sVisibilityConfig
settings. WAF doesn't automatically update the metric name when you update the rule name.Priority
— required — (Integer
)If you define more than one
Rule
in aWebACL
, WAF evaluates each request against theRules
in order based on the value ofPriority
. WAF processes rules with lower priority first. The priorities don't need to be consecutive, but they must all be different.Statement
— required — (map
)The WAF processing statement for the rule, for example ByteMatchStatement or SizeConstraintStatement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.ManagedRuleGroupStatement
— (map
)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 aNotStatement
orOrStatement
. 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.Note: You are charged additional fees when you use the WAF Bot Control managed rule groupAWSManagedRulesBotControlRuleSet
, the WAF Fraud Control account takeover prevention (ATP) managed rule groupAWSManagedRulesATPRuleSet
, or the WAF Fraud Control account creation fraud prevention (ACFP) managed rule groupAWSManagedRulesACFPRuleSet
. For more information, see WAF Pricing.VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Action
— (map
)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
andManagedRuleGroupStatement
.You must specify either this
Action
setting or the ruleOverrideAction
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.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
-
OverrideAction
— (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
RuleLabels
— (Array<map>
)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
, oripset
.
For example,
myLabelName
ornameSpace1:nameSpace2:myLabelName
.Name
— required — (String
)The label string.
-
VisibilityConfig
— required — (map
)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.SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations. If you don't specify this, WAF uses theCAPTCHA
configuration that's defined for the web ACL.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
VisibilityConfig
— (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.CustomResponseBodies
— (map<map>
)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 rule group, and then use them in the rules that you define in the rule group.
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.
ContentType
— required — (String
)The type of content in the payload that you are defining in the
Possible values include:Content
string."TEXT_PLAIN"
"TEXT_HTML"
"APPLICATION_JSON"
Content
— required — (String
)The payload of the custom response.
You can use JSON escape strings in JSON content. To do this, you must specify JSON content in the
ContentType
setting.For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextLockToken
— (String
)A token used for optimistic locking. WAF returns this token to your
update
requests. You useNextLockToken
in the same manner as you useLockToken
.
-
(AWS.Response)
—
Returns:
updateWebACL(params = {}, callback) ⇒ AWS.Request
Updates the specified WebACL. While updating a web ACL, WAF provides continuous coverage to the resources that you have associated with the web ACL.
Note: This operation completely replaces the mutable specifications that you already have for the web ACL with the ones that you provide to this call. To modify a web ACL, do the following:- Retrieve it by calling GetWebACL
- Update its settings as needed
- Provide the complete web ACL specification to this call
A web ACL defines a collection of rules to use to inspect and control web requests. Each rule has a statement that defines what to look for in web requests and an action that WAF applies to requests that match the statement. In the web ACL, you assign a default action to take (allow, block) for any request that does not match any of the rules. The rules in a web ACL can be a combination of the types Rule, RuleGroup, and managed rule group. You can associate a web ACL with one or more Amazon Web Services resources to protect. The resources can be an Amazon CloudFront distribution, an Amazon API Gateway REST API, an Application Load Balancer, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
Temporary inconsistencies during updates
When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
The following are examples of the temporary inconsistencies that you might notice during change propagation:
-
After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
-
After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
-
After you change a rule action setting, you might see the old action in some places and the new action in others.
-
After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
Service Reference:
Examples:
Calling the updateWebACL operation
var params = { DefaultAction: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Id: 'STRING_VALUE', /* required */ LockToken: 'STRING_VALUE', /* required */ Name: 'STRING_VALUE', /* required */ Scope: CLOUDFRONT | REGIONAL, /* required */ VisibilityConfig: { /* required */ CloudWatchMetricsEnabled: true || false, /* required */ MetricName: 'STRING_VALUE', /* required */ SampledRequestsEnabled: true || false /* required */ }, AssociationConfig: { RequestBody: { '<AssociatedResourceType>': { DefaultSizeInspectionLimit: KB_16 | KB_32 | KB_48 | KB_64 /* required */ }, /* '<AssociatedResourceType>': ... */ } }, CaptchaConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, ChallengeConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, CustomResponseBodies: { '<EntityName>': { Content: 'STRING_VALUE', /* required */ ContentType: TEXT_PLAIN | TEXT_HTML | APPLICATION_JSON /* required */ }, /* '<EntityName>': ... */ }, Description: 'STRING_VALUE', Rules: [ { Name: 'STRING_VALUE', /* required */ Priority: 'NUMBER_VALUE', /* required */ Statement: { /* Statement */ /* required */ AndStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, ByteMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, PositionalConstraint: EXACTLY | STARTS_WITH | ENDS_WITH | CONTAINS | CONTAINS_WORD, /* required */ SearchString: Buffer.from('...') || 'STRING_VALUE' /* Strings will be Base-64 encoded on your behalf */, /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, GeoMatchStatement: { CountryCodes: [ AF | AX | AL | DZ | AS | AD | AO | AI | AQ | AG | AR | AM | AW | AU | AT | AZ | BS | BH | BD | BB | BY | BE | BZ | BJ | BM | BT | BO | BQ | BA | BW | BV | BR | IO | BN | BG | BF | BI | KH | CM | CA | CV | KY | CF | TD | CL | CN | CX | CC | CO | KM | CG | CD | CK | CR | CI | HR | CU | CW | CY | CZ | DK | DJ | DM | DO | EC | EG | SV | GQ | ER | EE | ET | FK | FO | FJ | FI | FR | GF | PF | TF | GA | GM | GE | DE | GH | GI | GR | GL | GD | GP | GU | GT | GG | GN | GW | GY | HT | HM | VA | HN | HK | HU | IS | IN | ID | IR | IQ | IE | IM | IL | IT | JM | JP | JE | JO | KZ | KE | KI | KP | KR | KW | KG | LA | LV | LB | LS | LR | LY | LI | LT | LU | MO | MK | MG | MW | MY | MV | ML | MT | MH | MQ | MR | MU | YT | MX | FM | MD | MC | MN | ME | MS | MA | MZ | MM | NA | NR | NP | NL | NC | NZ | NI | NE | NG | NU | NF | MP | NO | OM | PK | PW | PS | PA | PG | PY | PE | PH | PN | PL | PT | PR | QA | RE | RO | RU | RW | BL | SH | KN | LC | MF | PM | VC | WS | SM | ST | SA | SN | RS | SC | SL | SG | SX | SK | SI | SB | SO | ZA | GS | SS | ES | LK | SD | SR | SJ | SZ | SE | CH | SY | TW | TJ | TZ | TH | TL | TG | TK | TO | TT | TN | TR | TM | TC | TV | UG | UA | AE | GB | US | UM | UY | UZ | VU | VE | VN | VG | VI | WF | EH | YE | ZM | ZW | XK, /* more items */ ], ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ } }, IPSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ IPSetForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE', /* required */ Position: FIRST | LAST | ANY /* required */ } }, LabelMatchStatement: { Key: 'STRING_VALUE', /* required */ Scope: LABEL | NAMESPACE /* required */ }, ManagedRuleGroupStatement: { Name: 'STRING_VALUE', /* required */ VendorName: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ManagedRuleGroupConfigs: [ { AWSManagedRulesACFPRuleSet: { CreationPath: 'STRING_VALUE', /* required */ RegistrationPagePath: 'STRING_VALUE', /* required */ RequestInspection: { /* required */ PayloadType: JSON | FORM_ENCODED, /* required */ AddressFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], EmailField: { Identifier: 'STRING_VALUE' /* required */ }, PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PhoneNumberFields: [ { Identifier: 'STRING_VALUE' /* required */ }, /* more items */ ], UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, EnableRegexInPath: true || false, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesATPRuleSet: { LoginPath: 'STRING_VALUE', /* required */ EnableRegexInPath: true || false, RequestInspection: { PasswordField: { /* required */ Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, /* required */ UsernameField: { /* required */ Identifier: 'STRING_VALUE' /* required */ } }, ResponseInspection: { BodyContains: { FailureStrings: [ /* required */ 'STRING_VALUE', /* more items */ ], SuccessStrings: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Header: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Name: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, Json: { FailureValues: [ /* required */ 'STRING_VALUE', /* more items */ ], Identifier: 'STRING_VALUE', /* required */ SuccessValues: [ /* required */ 'STRING_VALUE', /* more items */ ] }, StatusCode: { FailureCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ], SuccessCodes: [ /* required */ 'NUMBER_VALUE', /* more items */ ] } } }, AWSManagedRulesBotControlRuleSet: { InspectionLevel: COMMON | TARGETED, /* required */ EnableMachineLearning: true || false }, LoginPath: 'STRING_VALUE', PasswordField: { Identifier: 'STRING_VALUE' /* required */ }, PayloadType: JSON | FORM_ENCODED, UsernameField: { Identifier: 'STRING_VALUE' /* required */ } }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ], ScopeDownStatement: /* recursive Statement */, Version: 'STRING_VALUE' }, NotStatement: { Statement: /* recursive Statement */ }, OrStatement: { Statements: [ /* required */ /* recursive Statement */, /* more items */ ] }, RateBasedStatement: { AggregateKeyType: IP | FORWARDED_IP | CUSTOM_KEYS | CONSTANT, /* required */ Limit: 'NUMBER_VALUE', /* required */ CustomKeys: [ { Cookie: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, ForwardedIP: { }, HTTPMethod: { }, Header: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, IP: { }, LabelNamespace: { Namespace: 'STRING_VALUE' /* required */ }, QueryArgument: { Name: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, QueryString: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, UriPath: { TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, /* more items */ ], EvaluationWindowSec: 'NUMBER_VALUE', ForwardedIPConfig: { FallbackBehavior: MATCH | NO_MATCH, /* required */ HeaderName: 'STRING_VALUE' /* required */ }, ScopeDownStatement: /* recursive Statement */ }, RegexMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, RegexString: 'STRING_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RegexPatternSetReferenceStatement: { ARN: 'STRING_VALUE', /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, RuleGroupReferenceStatement: { ARN: 'STRING_VALUE', /* required */ ExcludedRules: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ], RuleActionOverrides: [ { ActionToUse: { /* required */ Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, SizeConstraintStatement: { ComparisonOperator: EQ | NE | LE | LT | GE | GT, /* required */ FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, Size: 'NUMBER_VALUE', /* required */ TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] }, SqliMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ], SensitivityLevel: LOW | HIGH }, XssMatchStatement: { FieldToMatch: { /* required */ AllQueryArguments: { }, Body: { OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Cookies: { MatchPattern: { /* required */ All: { }, ExcludedCookies: [ 'STRING_VALUE', /* more items */ ], IncludedCookies: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, HeaderOrder: { OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, Headers: { MatchPattern: { /* required */ All: { }, ExcludedHeaders: [ 'STRING_VALUE', /* more items */ ], IncludedHeaders: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ OversizeHandling: CONTINUE | MATCH | NO_MATCH /* required */ }, JA3Fingerprint: { FallbackBehavior: MATCH | NO_MATCH /* required */ }, JsonBody: { MatchPattern: { /* required */ All: { }, IncludedPaths: [ 'STRING_VALUE', /* more items */ ] }, MatchScope: ALL | KEY | VALUE, /* required */ InvalidFallbackBehavior: MATCH | NO_MATCH | EVALUATE_AS_STRING, OversizeHandling: CONTINUE | MATCH | NO_MATCH }, Method: { }, QueryString: { }, SingleHeader: { Name: 'STRING_VALUE' /* required */ }, SingleQueryArgument: { Name: 'STRING_VALUE' /* required */ }, UriPath: { } }, TextTransformations: [ /* required */ { Priority: 'NUMBER_VALUE', /* required */ Type: NONE | COMPRESS_WHITE_SPACE | HTML_ENTITY_DECODE | LOWERCASE | CMD_LINE | URL_DECODE | BASE64_DECODE | HEX_DECODE | MD5 | REPLACE_COMMENTS | ESCAPE_SEQ_DECODE | SQL_HEX_DECODE | CSS_DECODE | JS_DECODE | NORMALIZE_PATH | NORMALIZE_PATH_WIN | REMOVE_NULLS | REPLACE_NULLS | BASE64_DECODE_EXT | URL_DECODE_UNI | UTF8_TO_UNICODE /* required */ }, /* more items */ ] } }, VisibilityConfig: { /* required */ CloudWatchMetricsEnabled: true || false, /* required */ MetricName: 'STRING_VALUE', /* required */ SampledRequestsEnabled: true || false /* required */ }, Action: { Allow: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Block: { CustomResponse: { ResponseCode: 'NUMBER_VALUE', /* required */ CustomResponseBodyKey: 'STRING_VALUE', ResponseHeaders: [ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Captcha: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Challenge: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } } }, CaptchaConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, ChallengeConfig: { ImmunityTimeProperty: { ImmunityTime: 'NUMBER_VALUE' /* required */ } }, OverrideAction: { Count: { CustomRequestHandling: { InsertHeaders: [ /* required */ { Name: 'STRING_VALUE', /* required */ Value: 'STRING_VALUE' /* required */ }, /* more items */ ] } }, None: { } }, RuleLabels: [ { Name: 'STRING_VALUE' /* required */ }, /* more items */ ] }, /* more items */ ], TokenDomains: [ 'STRING_VALUE', /* more items */ ] }; wafv2.updateWebACL(params, function(err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response });
Parameters:
-
params
(Object)
(defaults to: {})
—
Name
— (String
)The name of the web ACL. You cannot change the name of a web ACL after you create it.
Scope
— (String
)Specifies whether this is for an Amazon CloudFront distribution or for a regional application. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
To work with CloudFront, you must also specify the Region US East (N. Virginia) as follows:
-
CLI - Specify the Region when you use the CloudFront scope:
--scope=CLOUDFRONT --region=us-east-1
. -
API and SDKs - For all calls, use the Region endpoint us-east-1.
"CLOUDFRONT"
"REGIONAL"
-
Id
— (String
)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.
DefaultAction
— (map
)The action to perform if none of the
Rules
contained in theWebACL
match.Block
— (map
)Specifies that WAF should block requests by default.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Specifies that WAF should allow requests by default.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Description
— (String
)A description of the web ACL that helps with identification.
Rules
— (Array<map>
)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.
Name
— required — (String
)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'sVisibilityConfig
settings. WAF doesn't automatically update the metric name when you update the rule name.Priority
— required — (Integer
)If you define more than one
Rule
in aWebACL
, WAF evaluates each request against theRules
in order based on the value ofPriority
. WAF processes rules with lower priority first. The priorities don't need to be consecutive, but they must all be different.Statement
— required — (map
)The WAF processing statement for the rule, for example ByteMatchStatement or SizeConstraintStatement.
ByteMatchStatement
— (map
)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.
SearchString
— required — (Buffer, Typed Array, Blob, String
)A string value that you want WAF to search for. WAF searches only in the part of web requests that you designate for inspection in FieldToMatch. The maximum length of the value is 200 bytes.
Valid values depend on the component that you specify for inspection in
FieldToMatch
:-
Method
: The HTTP method that you want WAF to search for. This indicates the type of operation specified in the request. -
UriPath
: The value that you want WAF to search for in the URI path, for example,/images/daily-ad.jpg
. -
JA3Fingerprint
: 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. You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
-
HeaderOrder
: The list of header names to match for. WAF creates a string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If
SearchString
includes alphabetic characters A-Z and a-z, note that the value is case sensitive.If you're using the WAF API
Specify a base64-encoded version of the value. The maximum length of the value before you base64-encode it is 200 bytes.
For example, suppose the value of
Type
isHEADER
and the value ofData
isUser-Agent
. If you want to search theUser-Agent
header for the valueBadBot
, you base64-encodeBadBot
using MIME base64-encoding and include the resulting value,QmFkQm90
, in the value ofSearchString
.If you're using the CLI or one of the Amazon Web Services SDKs
The value that you want WAF to search for. The SDK automatically base64 encodes the value.
-
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
PositionalConstraint
— required — (String
)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
, andSearchString
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
Possible values include:SearchString
must appear at the end of the specified part of the web request."EXACTLY"
"STARTS_WITH"
"ENDS_WITH"
"CONTAINS"
"CONTAINS_WORD"
-
SqliMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SensitivityLevel
— (String
)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:
Possible values include:LOW
"LOW"
"HIGH"
XssMatchStatement
— (map
)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.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
SizeConstraintStatement
— (map
)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
andJsonBody
settings for theFieldToMatch
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.FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
ComparisonOperator
— required — (String
)The operator to use to compare the request part to the size setting.
Possible values include:"EQ"
"NE"
"LE"
"LT"
"GE"
"GT"
Size
— required — (Integer
)The size, in byte, to compare to the request part, after any transformations.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
GeoMatchStatement
— (map
)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>
andawswaf: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>
andawswaf:forwardedip:geo:country:<ISO country code>
.For additional details, see Geographic match rule statement in the WAF Developer Guide.
CountryCodes
— (Array<String>
)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.
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
-
RuleGroupReferenceStatement
— (map
)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 aNotStatement
orOrStatement
. 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
— required — (String
)The Amazon Resource Name (ARN) of the entity.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
IPSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the IPSet that this statement references.
IPSetForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
Position
— required — (String
)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.
"FIRST"
"LAST"
"ANY"
-
RegexPatternSetReferenceStatement
— (map
)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
— required — (String
)The Amazon Resource Name (ARN) of the RegexPatternSet that this statement references.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
RateBasedStatement
— (map
)A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
Note: If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
-
IP address 10.1.1.1, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
-
IP address 127.0.0.0, HTTP method POST
-
IP address 10.1.1.1, HTTP method GET
The rule would create different aggregation instances according to your aggregation criteria, for example:
-
If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1: count 3
-
IP address 127.0.0.0: count 1
-
-
If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
-
HTTP method POST: count 2
-
HTTP method GET: count 2
-
-
If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
-
IP address 10.1.1.1, HTTP method POST: count 1
-
IP address 10.1.1.1, HTTP method GET: count 2
-
IP address 127.0.0.0, HTTP method POST: count 1
-
For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.
You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
You cannot nest a
RateBasedStatement
inside another statement, for example inside aNotStatement
orOrStatement
. You can define aRateBasedStatement
inside a web ACL and inside a rule group.For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.
If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call
GetRateBasedStatementManagedKeys
. This option is not available for other aggregation configurations.WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.
Limit
— required — (Integer
)The limit on requests per 5-minute period for a single aggregation instance for the rate-based rule. If the rate-based statement includes a
ScopeDownStatement
, this limit is applied only to the requests that match the statement.Examples:
-
If you aggregate on just the IP address, this is the limit on requests from any single IP address.
-
If you aggregate on the HTTP method and the query argument name "city", then this is the limit on requests for any single method, city pair.
-
EvaluationWindowSec
— (Integer
)The amount of time, in seconds, that WAF should include in its request counts, looking back from the current time. For example, for a setting of 120, when WAF checks the rate, it counts the requests for the 2 minutes immediately preceding the current time. Valid settings are 60, 120, 300, and 600.
This setting doesn't determine how often WAF checks the rate, but how far back it looks each time it checks. WAF checks the rate about every 10 seconds.
Default:
300
(5 minutes)AggregateKeyType
— required — (String
)Setting that indicates how to aggregate the request counts.
Note: Web requests that are missing any of the components specified in the aggregation keys are omitted from the rate-based rule evaluation and handling.-
CONSTANT
- Count and limit the requests that match the rate-based rule's scope-down statement. With this option, the counted requests aren't further aggregated. The scope-down statement is the only specification used. When the count of all requests that satisfy the scope-down statement goes over the limit, WAF applies the rule action to all requests that satisfy the scope-down statement.With this option, you must configure the
ScopeDownStatement
property. -
CUSTOM_KEYS
- Aggregate the request counts using one or more web request components as the aggregate keys.With this option, you must specify the aggregate keys in the
CustomKeys
property.To aggregate on only the IP address or only the forwarded IP address, don't use custom keys. Instead, set the aggregate key type to
IP
orFORWARDED_IP
. -
FORWARDED_IP
- Aggregate the request counts on the first IP address in an HTTP header.With this option, you must specify the header to use in the
ForwardedIPConfig
property.To aggregate on a combination of the forwarded IP address with other aggregate keys, use
CUSTOM_KEYS
. -
IP
- Aggregate the request counts on the IP address from the web request origin.To aggregate on a combination of the IP address with other aggregate keys, use
CUSTOM_KEYS
.
"IP"
"FORWARDED_IP"
"CUSTOM_KEYS"
"CONSTANT"
-
ForwardedIPConfig
— (map
)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.
Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.This is required if you specify a forwarded IP in the rule's aggregate key settings.
HeaderName
— required — (String
)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
.Note: If the specified header isn't present in the request, WAF doesn't apply the rule to the web request at all.FallbackBehavior
— required — (String
)The match status to assign to the web request if the request doesn't have a valid IP address in the specified position.
Note: 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.
"MATCH"
"NO_MATCH"
-
CustomKeys
— (Array<map>
)Specifies the aggregate keys to use in a rate-base rule.
Header
— (map
)Use the value of a header in the request as an aggregate key. Each distinct value in the header contributes to the aggregation instance. If you use a single header as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the header to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Cookie
— (map
)Use the value of a cookie in the request as an aggregate key. Each distinct value in the cookie contributes to the aggregation instance. If you use a single cookie as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the cookie to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryArgument
— (map
)Use the specified query argument as an aggregate key. Each distinct value for the named query argument contributes to the aggregation instance. If you use a single query argument as your custom key, then each value fully defines an aggregation instance.
Name
— required — (String
)The name of the query argument to use.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
QueryString
— (map
)Use the request's query string as an aggregate key. Each distinct string contributes to the aggregation instance. If you use just the query string as your custom key, then each string fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
HTTPMethod
— (map
)Use the request's HTTP method as an aggregate key. Each distinct HTTP method contributes to the aggregation instance. If you use just the HTTP method as your custom key, then each method fully defines an aggregation instance.
ForwardedIP
— (map
)Use the first IP address in an HTTP header as an aggregate key. Each distinct forwarded IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the forwarded IP address by specifying
FORWARDED_IP
in your rate-based statement'sAggregateKeyType
.With this option, you must specify the header to use in the rate-based rule's
ForwardedIPConfig
property.IP
— (map
)Use the request's originating IP address as an aggregate key. Each distinct IP address contributes to the aggregation instance.
When you specify an IP or forwarded IP in the custom key settings, you must also specify at least one other key to use. You can aggregate on only the IP address by specifying
IP
in your rate-based statement'sAggregateKeyType
.LabelNamespace
— (map
)Use the specified label namespace as an aggregate key. Each distinct fully qualified label name that has the specified label namespace contributes to the aggregation instance. If you use just one label namespace as your custom key, then each label name fully defines an aggregation instance.
This uses only labels that have been added to the request by rules that are evaluated before this rate-based rule in the web ACL.
For information about label namespaces and names, see Label syntax and naming requirements in the WAF Developer Guide.
Namespace
— required — (String
)The namespace to use for aggregation.
UriPath
— (map
)Use the request's URI path as an aggregate key. Each distinct URI path contributes to the aggregation instance. If you use just the URI path as your custom key, then each URI path fully defines an aggregation instance.
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
-
AndStatement
— (map
)A logical rule statement used to combine other rule statements with AND logic. You provide more than one Statement within the
AndStatement
.Statements
— required — (Array<map>
)The statements to combine with AND logic. You can use any statements that can be nested.
OrStatement
— (map
)A logical rule statement used to combine other rule statements with OR logic. You provide more than one Statement within the
OrStatement
.Statements
— required — (Array<map>
)The statements to combine with OR logic. You can use any statements that can be nested.
NotStatement
— (map
)A logical rule statement used to negate the results of another rule statement. You provide one Statement within the
NotStatement
.ManagedRuleGroupStatement
— (map
)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 aNotStatement
orOrStatement
. 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.Note: You are charged additional fees when you use the WAF Bot Control managed rule groupAWSManagedRulesBotControlRuleSet
, the WAF Fraud Control account takeover prevention (ATP) managed rule groupAWSManagedRulesATPRuleSet
, or the WAF Fraud Control account creation fraud prevention (ACFP) managed rule groupAWSManagedRulesACFPRuleSet
. For more information, see WAF Pricing.VendorName
— required — (String
)The name of the managed rule group vendor. You use this, along with the rule group name, to identify a rule group.
Name
— required — (String
)The name of the managed rule group. You use this, along with the vendor name, to identify the rule group.
Version
— (String
)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.
ExcludedRules
— (Array<map>
)Rules in the referenced rule group whose actions are set to
Count
.Note: Instead of this option, useRuleActionOverrides
. It accepts any valid action setting, includingCount
.Name
— required — (String
)The name of the rule whose action you want to override to
Count
.
ManagedRuleGroupConfigs
— (Array<map>
)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.
LoginPath
— (String
)Note: Instead of this setting, provide your configuration underAWSManagedRulesATPRuleSet
.PayloadType
— (String
)Note: Instead of this setting, provide your configuration under the request inspection configuration forPossible values include:AWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
."JSON"
"FORM_ENCODED"
UsernameField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 isusername1
-
PasswordField
— (map
)Note: Instead of this setting, provide your configuration under the request inspection configuration forAWSManagedRulesATPRuleSet
orAWSManagedRulesACFPRuleSet
.Identifier
— required — (String
)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 ispassword1
.
-
AWSManagedRulesBotControlRuleSet
— (map
)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.
InspectionLevel
— required — (String
)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.
Possible values include:"COMMON"
"TARGETED"
EnableMachineLearning
— (Boolean
)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
andTGT_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
AWSManagedRulesATPRuleSet
— (map
)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.
LoginPath
— required — (String
)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.RequestInspection
— (map
)The criteria for inspecting login requests, used by the ATP rule group to validate credentials usage.
PayloadType
— required — (String
)The payload type for your login endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— required — (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— required — (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to login requests, used by the ATP rule group to track login failure rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the login page path.
AWSManagedRulesACFPRuleSet
— (map
)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.
CreationPath
— required — (String
)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
.RegistrationPagePath
— required — (String
)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.
Note: This page must acceptGET
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
.RequestInspection
— required — (map
)The criteria for inspecting account creation requests, used by the ACFP rule group to validate and track account creation attempts.
PayloadType
— required — (String
)The payload type for your account creation endpoint, either JSON or form encoded.
Possible values include:"JSON"
"FORM_ENCODED"
UsernameField
— (map
)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 isusername1
Identifier
— required — (String
)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 isusername1
-
-
PasswordField
— (map
)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 ispassword1
.
Identifier
— required — (String
)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 ispassword1
.
-
-
EmailField
— (map
)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 isemail1
.
Identifier
— required — (String
)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 isemail1
.
-
-
PhoneNumberFields
— (Array<map>
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
Identifier
— required — (String
)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
, andprimaryphoneline3
, the phone number field identifiers areprimaryphoneline1
,primaryphoneline2
, andprimaryphoneline3
.
-
-
AddressFields
— (Array<map>
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
Identifier
— required — (String
)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
, andprimaryaddressline3
, the address fields identifiers areprimaryaddressline1
,primaryaddressline2
, andprimaryaddressline3
.
-
-
ResponseInspection
— (map
)The criteria for inspecting responses to account creation requests, used by the ACFP rule group to track account creation success rates.
Note: 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.
StatusCode
— (map
)Configures inspection of the response status code for success and failure indicators.
SuccessCodes
— required — (Array<Integer>
)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 ]
FailureCodes
— required — (Array<Integer>
)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 ]
Header
— (map
)Configures inspection of the response header for success and failure indicators.
Name
— required — (String
)The name of the header to match against. The name must be an exact match, including case.
JSON example:
"Name": [ "RequestResult" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
BodyContains
— (map
)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.
SuccessStrings
— required — (Array<String>
)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!" ]
FailureStrings
— required — (Array<String>
)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" ]
Json
— (map
)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.
Identifier
— required — (String
)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" ]
SuccessValues
— required — (Array<String>
)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" ]
FailureValues
— required — (Array<String>
)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" ]
EnableRegexInPath
— (Boolean
)Allow the use of regular expressions in the registration page path and the account creation path.
-
RuleActionOverrides
— (Array<map>
)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.Name
— required — (String
)The name of the rule to override.
ActionToUse
— required — (map
)The override action to use, in place of the configured action of the rule in the rule group.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
LabelMatchStatement
— (map
)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.
Scope
— required — (String
)Specify whether you want to match using the label name or just the namespace.
Possible values include:"LABEL"
"NAMESPACE"
Key
— required — (String
)The string to match against. The setting you provide for this depends on the match statement's
Scope
setting:-
If the
Scope
indicatesLABEL
, 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
indicatesNAMESPACE
, 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
.-
RegexMatchStatement
— (map
)A rule statement used to search web request components for a match against a single regular expression.
RegexString
— required — (String
)The string representing the regular expression.
FieldToMatch
— required — (map
)The part of the web request that you want WAF to inspect.
SingleHeader
— (map
)Inspect a single header. Provide the name of the header to inspect, for example,
User-Agent
orReferer
. 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
— required — (String
)The name of the query header to inspect.
SingleQueryArgument
— (map
)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
— required — (String
)The name of the query argument to inspect.
AllQueryArguments
— (map
)Inspect all query arguments.
UriPath
— (map
)Inspect the request URI path. This is the part of the web request that identifies a resource, for example,
/images/daily-ad.jpg
.QueryString
— (map
)Inspect the query string. This is the part of a URL that appears after a
?
character, if any.Body
— (map
)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.OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Method
— (map
)Inspect the HTTP method. The method indicates the type of operation that the request is asking the origin to perform.
JsonBody
— (map
)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.MatchPattern
— required — (map
)The patterns to look for in the JSON body. WAF inspects the results of these pattern matches against the rule inspection criteria.
All
— (map
)Match all of the elements. See also
MatchScope
in JsonBody.You must specify either this setting or the
IncludedPaths
setting, but not both.IncludedPaths
— (Array<String>
)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.Note: Don't use this option to include all paths. Instead, use theAll
setting.
MatchScope
— required — (String
)The parts of the JSON to match against using the
MatchPattern
. If you specifyALL
, 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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
InvalidFallbackBehavior
— (String
)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.
Note: 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.Possible values include:"MATCH"
"NO_MATCH"
"EVALUATE_AS_STRING"
-
OversizeHandling
— (String
)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
orNO_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:
Possible values include:CONTINUE
"CONTINUE"
"MATCH"
"NO_MATCH"
-
-
Headers
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedHeaders
.Example JSON:
"MatchPattern": { "ExcludedHeaders": [ "KeyToExclude1", "KeyToExclude2" ] }
All
— (map
)Inspect all headers.
IncludedHeaders
— (Array<String>
)Inspect only the headers that have a key that matches one of the strings specified here.
ExcludedHeaders
— (Array<String>
)Inspect only the headers whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
Cookies
— (map
)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.MatchPattern
— required — (map
)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
, orExcludedCookies
.Example JSON:
"MatchPattern": { "IncludedCookies": [ "session-id-time", "session-id" ] }
All
— (map
)Inspect all cookies.
IncludedCookies
— (Array<String>
)Inspect only the cookies that have a key that matches one of the strings specified here.
ExcludedCookies
— (Array<String>
)Inspect only the cookies whose keys don't match any of the strings specified here.
MatchScope
— required — (String
)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 logicalAND
statement to combine two match rules, one that inspects the keys and another that inspects the values."ALL"
"KEY"
"VALUE"
OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
HeaderOrder
— (map
)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
.OversizeHandling
— required — (String
)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.
"CONTINUE"
"MATCH"
"NO_MATCH"
-
JA3Fingerprint
— (map
)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.
Note: You can use this choice only with a string matchByteMatchStatement
with thePositionalConstraint
set toEXACTLY
.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.
FallbackBehavior
— required — (String
)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.
"MATCH"
"NO_MATCH"
-
TextTransformations
— required — (Array<map>
)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
— required — (Integer
)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
— required — (String
)For detailed descriptions of each of the transformation types, see Text transformations in the WAF Developer Guide.
Possible values include:"NONE"
"COMPRESS_WHITE_SPACE"
"HTML_ENTITY_DECODE"
"LOWERCASE"
"CMD_LINE"
"URL_DECODE"
"BASE64_DECODE"
"HEX_DECODE"
"MD5"
"REPLACE_COMMENTS"
"ESCAPE_SEQ_DECODE"
"SQL_HEX_DECODE"
"CSS_DECODE"
"JS_DECODE"
"NORMALIZE_PATH"
"NORMALIZE_PATH_WIN"
"REMOVE_NULLS"
"REPLACE_NULLS"
"BASE64_DECODE_EXT"
"URL_DECODE_UNI"
"UTF8_TO_UNICODE"
Action
— (map
)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
andManagedRuleGroupStatement
.You must specify either this
Action
setting or the ruleOverrideAction
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.
Block
— (map
)Instructs WAF to block the web request.
CustomResponse
— (map
)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.
ResponseCode
— required — (Integer
)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.
CustomResponseBodyKey
— (String
)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 actionBlockAction
setting, you reference the response body using this key.ResponseHeaders
— (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Allow
— (map
)Instructs WAF to allow the web request.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Count
— (map
)Instructs WAF to count the web request and then continue evaluating the request using the remaining rules in the web ACL.
CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Captcha
— (map
)Instructs WAF to run a
CAPTCHA
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
Challenge
— (map
)Instructs WAF to run a
Challenge
check against the web request.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
-
OverrideAction
— (map
)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
andManagedRuleGroupStatement
.Note: 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, withCount
action, in your rule group reference statement settings.Count
— (map
)Override the rule group evaluation result to count only.
Note: 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, withCount
action, in your rule group reference statement settings.CustomRequestHandling
— (map
)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.
InsertHeaders
— required — (Array<map>
)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
— required — (String
)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 namesample
, WAF inserts the headerx-amzn-waf-sample
.Value
— required — (String
)The value of the custom header.
None
— (map
)Don't override the rule group evaluation result. This is the most common setting.
RuleLabels
— (Array<map>
)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
, oripset
.
For example,
myLabelName
ornameSpace1:nameSpace2:myLabelName
.Name
— required — (String
)The label string.
-
VisibilityConfig
— required — (map
)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.SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations. If you don't specify this, WAF uses theCAPTCHA
configuration that's defined for the web ACL.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
VisibilityConfig
— (map
)Defines and enables Amazon CloudWatch metrics and web request sample collection.
SampledRequestsEnabled
— required — (Boolean
)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.
Note: 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.CloudWatchMetricsEnabled
— required — (Boolean
)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.
MetricName
— required — (String
)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
andDefault_Action
.
LockToken
— (String
)A token used for optimistic locking. WAF returns a token to your
get
andlist
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 likeupdate
anddelete
. 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 aWAFOptimisticLockException
. If this happens, perform anotherget
, and use the new token returned by that operation.CustomResponseBodies
— (map<map>
)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.
ContentType
— required — (String
)The type of content in the payload that you are defining in the
Possible values include:Content
string."TEXT_PLAIN"
"TEXT_HTML"
"APPLICATION_JSON"
Content
— required — (String
)The payload of the custom response.
You can use JSON escape strings in JSON content. To do this, you must specify JSON content in the
ContentType
setting.For information about the limits on count and size for custom request and response settings, see WAF quotas in the WAF Developer Guide.
CaptchaConfig
— (map
)Specifies how WAF should handle
CAPTCHA
evaluations for rules that don't have their ownCaptchaConfig
settings. If you don't specify this, WAF uses its default settings forCaptchaConfig
.ImmunityTimeProperty
— (map
)Determines how long a
CAPTCHA
timestamp in the token remains valid after the client successfully solves aCAPTCHA
puzzle.ImmunityTime
— required — (Integer
)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.
ChallengeConfig
— (map
)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 forChallengeConfig
.ImmunityTimeProperty
— (map
)Determines how long a challenge timestamp in the token remains valid after the client successfully responds to a challenge.
ImmunityTime
— required — (Integer
)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.
TokenDomains
— (Array<String>
)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.
Example JSON:
"TokenDomains": { "mywebsite.com", "myotherwebsite.com" }
Public suffixes aren't allowed. For example, you can't use
gov.au
orco.uk
as token domains.AssociationConfig
— (map
)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).
Note: 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).
RequestBody
— (map<map>
)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.
Note: 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).
DefaultSizeInspectionLimit
— required — (String
)Specifies the maximum size of the web request body component that an associated CloudFront, API Gateway, Amazon Cognito, App Runner, or Verified Access resource should send to WAF for inspection. This applies to statements in the web ACL that inspect the body or JSON body.
Default:
Possible values include:16 KB (16,384 bytes)
"KB_16"
"KB_32"
"KB_48"
"KB_64"
Callback (callback):
-
function(err, data) { ... }
Called when a response from the service is returned. If a callback is not supplied, you must call AWS.Request.send() on the returned request object to initiate the request.
Context (this):
-
(AWS.Response)
—
the response object containing error, data properties, and the original request object.
Parameters:
-
err
(Error)
—
the error object returned from the request. Set to
null
if the request is successful. -
data
(Object)
—
the de-serialized data returned from the request. Set to
null
if a request error occurs. Thedata
object has the following properties:NextLockToken
— (String
)A token used for optimistic locking. WAF returns this token to your
update
requests. You useNextLockToken
in the same manner as you useLockToken
.
-
(AWS.Response)
—
Returns:
Generated on Wed Nov 6 18:52:02 2024 by yard 0.9.36 (ruby-2.5.1). - updateRuleGroup(params = {}, callback) ⇒ AWS.Request