Supported Features

Bypass Monitor Header

When enabling the enforcer for the first time, it is recommended to do so in monitor mode to collect data before actually starting to block user requests. Prior to switching the module mode to active_blocking entirely, it's also crucial to verify that the full blocking flow works as expected. This feature activates the full blocking flow even while in monitor mode if a particular header is present on the request.

Cookie V3

The latest version of our risk cookie, which includes encrypted content and more relevant information regarding the user (e.g., the risk score is between 0 and 100).

CSS Ref

Provides a way to include an additional custom .css file to add to the block page.

Custom Cookie Header

Allows to set a header name which is used to extract the PerimeterX cookies, instead of using the request cookies property.

Custom Logo

Adds a custom logo to the block page that will be shown to users. This aligns the block page with the customer's brand.

Enforced Routes

Defines a list of routes (as strings or regular expressions) which should always be enforced with no exceptions.

Filter By HTTP Method

Filters out requests according to their HTTP Method, avoiding unnecessary traffic in the enforcer verification flow and reducing operation costs.

Filter By IP

Filters out requests according to their IP address, avoiding unnecessary traffic in the enforcer verification flow and reducing operation costs.

Filter By Route

Routes (endpoints) specified here will not be blocked, regardless of the score they receive. A client request to an allowed route will not generate any risk or async activities.

Filter By User Agent

Filters out requests according to their user agent value, avoiding unnecessary traffic in the enforcer verification flow and reducing operation costs.

First Party

To prevent suspicious or unwanted behavior on the client side, some browsers or extensions (such as an Adblock extension) may deny the frontend JavaScript code from making requests to other domains. This prevents the PerimeterX sensor from making requests to the PerimeterX backends, which greatly limits PerimeterX's detection capabilities. To avoid this problem, first_party enables the enforcer to be used as a proxy for PerimeterX servers, and to serve content to the browser from a first party endpoint (i.e., an endpoint on the customer’s domain).

JS Ref

Provides a way to include a custom JS script to add to the block page. This script will run after the default JS scripts.

Module Enable

This feature serves as an on/off switch for the entire module, providing a way to enable and disable all PerimeterX capabilities quickly and easily.

Module Mode

This feature controls the behavior of the enforcer by changing how it executes certain parts of the workflow. Most notably, different modes allow for analysis and fine-tuning of the enforcer behavior without serving block pages that affect end users.

Monitored Routes

Enables certain endpoints to be monitored rather than enforced by PerimeterX, even when the enforcer is in active blocking mode.

Sensitive Headers

The PerimeterX detector requires information about the HTTP request as part of its bot detections. Certain headers may contain information that should not be forwarded to other servers, including the PerimeterX backend. Configuring these header names as sensitive headers will remove these headers from requests sent to other backends by PerimeterX.

Sensitive Routes

Certain endpoints may require more stringent protection from bot attacks (e.g., endpoints that execute payments or handle personal information). In these cases, routes can be configured as sensitive routes, meaning risk API calls will be made even if the request contains a valid, unexpired cookie.


Did this page help you?