Configure the Input Validation behavior

In Property Manager, behaviors apply certain features to your configuration. Behaviors help shape how requests passing through the ​Akamai​ network are handled and processed.

How to

  1. Access Property Manager configurations associated with the selected ​Akamai Control Center​ account. Go to > CDN > Properties (or just enter Properties in the search box).

    The Property Groups page opens.

  2. Select the property and version you want to add your Cloudlet to.

  3. Click Add Behavior, then select Input Validation.

  4. Complete the following fields:

Field

Description

Standard Fields

Enable

Set to On.

Policy Name

Select an existing Cloudlets policy to use with this behavior. You create policies in Cloudlets Policy Manager.

Instance Label

Enter the label to use to distinguish this Input Validation policy from others in the same property.

User Identification

By Cookie Value

Enable to identify users by the value of a cookie. If you enable multiple identification types, the values for all types must match for the user to be identified across requests.

Cookie Name

If you enable By Cookie Value, enter the name of a cookie whose value will be used for user identification. User identification occurs when the value of the cookie is the same across all requests. The value can be absent or blank.

By IP Address

Enable to identify users by their IP address. You may want to disable this option if you are concerned about DDoS attacks from various IP addresses.

If you enable multiple identification types, the values for all types must match for the user to be identified across requests.

By Request Headers

Enable to identify users by specific parameters from either GET or POST requests.

If you enable multiple identification types, the values for all types must match for the user to be identified across requests.

Headers

If you enable By Request Headers, enter the request headers that will identify a user. The value can be absent or blank.

User identification occurs when the value of the headers listed is the same across all requests.

If you list multiple headers, they will be evaluated as a group, not individually, for user identification.

By Request Parameters

Enable to identify users by specific request parameters. These will be either GET or POST parameters depending on the request method.

If you enable multiple identification types, the values for all types must match for the user to be identified across requests.

Parameters

If you enable By Request Parameters, enter the request parameters that will identify a user. The value can be absent or blank.

User identification occurs when the value of the parameters listed is the same across all requests.

If you list multiple parameters, they will be evaluated as a group, not individually, for user identification.

Validation Behavior

On Large POST Body

Select to either fail POST request bodies greater than 16 KB, or permit them to pass without any validation for policy compliance. Input Validation can't inspect POST request bodies that are greater than 16 KB.

On Valid Request

Select how a valid request affects the counting of invalid requests. You can reset the counter to 0 after a valid request, or continue the count and increment to include the successful request.

Validation on Origin

Select how the origin indicates an invalid request. Because some types of invalid input cannot be detected at the network edge, you can use this setting to perform further validation at the origin.

You can use an HTTP status code or a combination of status code and a response header to indicate invalid requests. You can also disable this field.

Origin Status Code

If you enabled validation on origin, specify the HTTP response code the origin uses to indicate that a request validation failed.

Origin Header Name

If you enabled validation by status code and header, enter the HTTP response header that the origin will use to indicate a request validation failure. The response includes this header when a failure occurs.

Origin Header Value

If you enabled validation by status code and header, enter the value of the origin header to use to indicate a validation failure.

Redirect URL

Specify where to redirect requests once the penalty behavior is triggered.

Penalty Behavior

Tries Before Penalty

Enter the number of validation failures or attempts permitted before the penalty behavior is triggered. When the counter hits this threshold, the penalty is triggered.

On Penalty

Select the action to take when a user is being penalized for too many validation failures or attempts. You can select a 302 temporary redirect, deny with a 403 forbidden error, or deny with a branded 403 error page.

Note: The duration of the penalty is five minutes.

Redirect URL

If you select a 302 redirect as the penalty, specify where to redirect requests once the penalty threshold is met.

NetStorage Account

If displaying a branded 403 page on penalty, specify the NetStorage account that contains the static content page served.

NetStorage Path

If displaying a branded 403 page on penalty, enter the NetStorage path for the page.

Note: If you have an Origin Base Path behavior in your property, it won't be included in this path.

Branded Response Cache TTL (min)

If displaying a branded 403 page on penalty, select a time between 5 and 30 minutes that the 403 page will reside in cache. This time period is known as the time to live (TTL).

  1. Click Save.

  2. Activate the newly updated property.


Did this page help you?