The following features are supported in the latest Cloudflare worker enforcer (Version 4.0.4):
The additional activity handler is a callback function passed to the enforcer. The enforcer runs this callback after sending
block activity to the collector, and before forwarding the request to the next step in the pipeline. A common use case of the additional activity handler is to set the score as a variable or header. Then the application can read the score and do what is defined within the application's logic.
In specific cases (e.g., XHR post requests), a full captcha page render might not be an option. In such cases the advanced blocking response returns a JSON object containing all the information needed to render a customized captcha challenge implementation - be it a popup modal, a section on the page, etc. This allows for flexibility and customizability in terms of how the captcha pages are displayed.
A captcha page is one of the possible response types returned to the client as a result of a request blocked by the enforcer. In the case of a request with a high risk score, the user receives an HTML page presenting a captcha challenge to solve.
A block page is one of the possible response types returned to the client as a result of a request blocked by the enforcer. In the case of a request with a high risk score, the user receives an HTML block page that cannot be passed.
Rate limit is one of the possible response types returned to the client as a result of a request blocked by the enforcer. Rate Limit means that in case of a request with high score, the user receives an HTML page with the rate limit response code (429).
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.
The real client IP is included in the information that the enforcer gathers and sends. When the request passes through a proxy or a load balancer before reaching the customer’s application, the module considers the internal IP as the user's IP by default. The
px_ip_headers configuration defines which headers will contain the user's real IP, as set by a previous network component. The enforcer will try to extract the IP from these headers. If no IP exists, it will fall back to the IP of the machine it is directly connected to. If IP extraction is more complex than configuring a header, this enforcer also supports defining a custom function to extract the user IP.
csp_support protects from cross-site scripting attacks, code injections attacks and Magecart attacks that manipulate the website's functionality. During mitigation, Code Defender updates the policy to restrict the specific resources, and the browser blocks all communication with them.
Provides a way to include an additional custom .css file to add to the block page.
Allows to set a header name which is used to extract the PerimeterX cookies, instead of using the request cookies property.
Adds a custom logo to the block page that will be shown to users. This aligns the block page with the customer's brand.
This feature enriches activities sent from the enforcer to PerimeterX with additional custom data. This data can include user information, session IDs, or other data that PerimeterX should have access to. These custom parameters are defined by a configurable function that must return an object that contains these custom parameters. There is a limit of 10 custom parameters.
Defines a list of routes (as strings or regular expressions) which should always be enforced with no exceptions.
The ability to filter requests from the enforcer verification flow by specific header & its value.
Filters out requests according to their IP address, avoiding unnecessary traffic in the enforcer verification flow and reducing operation costs.
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.
Filters out requests according to their user agent value, avoiding unnecessary traffic in the enforcer verification flow and reducing operation costs.
PerimeterX does not enforce static assets such as images and documents. To prevent unnecessary API calls to PerimeterX servers and needless computation, the enforcer filters all requests with a valid static file extension.
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).
As GraphQL allows to follow references between multiple resources in a single API request, it is commonly implemented so all API calls are directed to a single endpoint. The GraphQL operation which resides in the payload of the request, changes according to the action being taken (e.g. login, checkout, product info) and acts as an identifier for the request's purpose. The GraphQL detection enhancement feature is automatically enabled (no configuration needed) on supported enforcers & allows PerimeterX to look into the payload of the GraphQL request and retrieve valuable information to enhance our detections, including the operation name & type.
This feature enables the Hype Sales Protection offering, served instead of CAPTCHA challenges. the Hype Sale Challenge provides a user-friendly way of weeding out bot traffic while enabling the site to handle traffic surges. Unlike many legacy tools, the Hype Sale Challenge shifts the focus from blocking bots to allowing humans through.
Provides a way to include a custom JS script to add to the block page. This script will run after the default JS scripts.
Adds login information to risk API calls to identify compromised credentials as part of the Credentials Intelligence solution.
The enforcer recognizes and handles requests coming from PerimeterX Mobile SDK. Because mobile apps do not add cookies as part of the HTTP requests, the PX cookies are sent as headers instead. Mobile user-agents may change during the flow of the app, so the mobile 'cookies' are not signed with user-agent and are considered as tokens.
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.
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.
Enables certain endpoints to be monitored rather than enforced by PerimeterX, even when the enforcer is in active blocking mode.
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. In case the endpoint is via GraphQL, multiple operations will share the same route thus hurting the ability to configure specific operations as sensitive. To avoid this issue we extract the operation name & type from the request payload for GraphQL endpoints and allow to configure values of these properties as sensitive.
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.
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.
Auto inject a custom JS snippet to the client’s HTML pages which can be controlled remotely, allowing the flexibility to modify the snippet without having to deploy changes to the production environment. This feature helps ease the onboarding process as the snippet will be automatically added to the HTML response, simplify upgrades by not requiring to deploy changes to the production environment, and bypasses Ad blockers that attempt to block out going requests by the snippet to retrieve PerimeterX sensor.
enforcer_telemetry activity is sent to PerimeterX servers whenever the enforcer receives a telemetry command. This activity provides information directly to PerimeterX about the current environment and configuration of the enforcer.
The visitor ID (VID) is an identifier used by PerimeterX to identify clients during and across sessions. The VID is crucial for detection, and any mishandling of this feature could decrease its accuracy.
The PerimeterX hashed data (PXHD) cookie is responsible for linking the first risk request with the browser activities (sensor) for better user tracking. This cookie can also be used for sharing additional information between the PerimeterX backend, enforcer, and the sensor.
The User Identifiers are used by PerimeterX to identify clients during and across sessions. The identifiers are:
JWT - JSON Web Token is an encrypted token that holds a JSON object which contains meta data on the user
request, including the app user ID. It can be stored in a cookie or header.
CTS - Cross Tab Session represented by a token that is stored on the
Updated about 2 months ago