Create Rules

Define a filter to determine when the rule is applied.

The filter defines the conditions that trigger the rule action. If left empty, the rule is always run.

The rule filter can include up to 2048 characters.

For details, see Define a rule filter.

Define the action you want Imperva to take for every request that matches the rule.

For details, see:

• Delivery actions
• Security actions
• Create Rate Rules
• Create Simplified Redirect Rules

Give the rule a meaningful name.

Note:

• The Rule Name may not contain special characters. Only alphanumeric, space, period (“.”), and underscore (“_”) characters are allowed.
• Rate Rules: A rate rule name may not contain special characters, including the underscore ("_") character or periods ("."). Only alphanumeric characters, hyphens ("-"), and spaces are allowed.

Enable or disable the rule.

Note: The rule must be enabled if you want to use the Test Rule option below.

Available for Security rules only.

Activates the rule for a select number of IPs only. When you create a rule, Imperva will detect your IP and use that as the default IP for testing.

Rules propagate across the system immediately to ensure that changes are applied in near real time.

In order to minimize the risk to your production environment, it’s recommended to activate a new or modified rule in test mode prior to activating in production.

Under If, select the part of the request or the sessions to which the filter is applied. For example, Client IP or Country. For full details on the available parameters, see Rule Filter Parameters.

Defines how the filter value is matched.

Most filter parameters support only a subset of the list of operators. For example, the QueryString filter parameter supports only the ‘equal to’ and ‘not equal to’ operators. When a filter parameter is selected (see Matched object above), only the supported operators will be displayed in the operator field.

For the full list of filter parameters and the supported operators for each, see Rule Filter Parameters.

When you define a filter and click +Add, the filter syntax is added to the Editor. You can add as many filters as required. The filters are added to the rule syntax using the AND logic. For information about combining filters using the OR logic, refer to the Syntax Guide.

Alternatively, you can add filters directly using the native syntax. Every rule is checked for syntax validity before it is saved. For details, see the Syntax Guide.

Note: When defining application delivery rules (not security rules) an empty rule filter will match any request.

Modifies the path to which a specific request is targeted. In such a case, the client enters a certain path in his browser, while the server uses a different path to serve the requested resource.

User enters www.mysite.com/football in his browser and is served by the www.mysite.com/sport/football page with no change to the request line.

Notes:

• The URL doesn’t include the scheme or host name/domain - only the request path.
• The URL should start with a “/”.
• If the host name/domain needs to be rewritten, a header rewrite action rule for the Host header should be defined.
• Wildcards and variables are supported in URL rewrite.

Modifies or adds a request header before passing traffic to the origin server.

The user has to indicate the header name, whether the header should be added if it is absent from the original request, and the new header value.

When rewriting the Host header, the following aspects should be kept in mind:

• Host header modification affects SNI host name as well
• In case the modified Host header value (host name/domain) is served from a different origin server, a Forward rule should be configured to direct the request to the appropriate origin server (data center)

Notes:

• To add a header that is absent from the original request, use the Add new if missing option.
• Wildcards and variables are supported in Header rewrite.
• A header can be removed using the Remove Header action.
• The following headers are restricted and cannot be rewritten: Cache-Control, Content-Type, Content-Length, Transfer-Encoding and Content-Encoding.

Removes a specific request header so that it won’t be sent to the origin server.

In this example, the X-Old-Header header will be removed from any request in which it appears.

Remove multiple header occurrences: Removes all occurrences of the specified header from the request. By default, only the first occurrence of the header is removed

Modifies or adds cookies that are sent by the client to the origin server. The cookie name and value should be indicated.

If the web application expects to receive a cookie to identify a specific client characteristic (e.g., device type), a new cookie can be sent to the origin without actually setting a cookie on the client side (the cookie is created on the Imperva edge and sent to the origin).

The value of the theme cookie will be set to light for requests towards the origin (theme=light).

Notes:

• To add a cookie that is absent from the original request, use the Add new if missing option.
• Wildcards and variables can be used for cookie rewrite.
• A cookie can be removed using the Remove Cookie action.

Modifies or adds a response header before passing the response back to the client.

Enter the header name, the new header value, and whether the header should be added if it is absent from the original response.

Note: The following headers are restricted and cannot be rewritten: Cache-Control, Content-Type, Content-Length, Transfer-Encoding and Content-Encoding.

Removes a specific response header so that it won’t be sent back to the client.

In this example, the X-Old-Header header will be removed from any response in which it appears.

Remove multiple header occurrences: Removes all occurrences of the specified header from the response. By default, only the first occurrence of the header is removed

Modifies the status code in the response from the origin server before sending it back to the client.

The Response Status Code field accepts any 3-digit number.

Select the data center to which a specific request will be sent.

The target data center can include a single origin server or multiple origin servers in a load balanced mode.

To use a data center for forwarding, select the Support only forward rules option on the Origin Server settings page.

Data centers that are configured to support forwarding can accept requests only through the Forward rule, and cannot be used to support Global Server Load Balancing.

GSLB between Data Centers used for Forwarding is not supported.

The data centers that are configured to support forwarding are displayed in the Target Data Center dropdown list.