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 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).
  5. Click Save.
  6. Activate the newly updated property.