- 15 Jan 2024
- Print
- DarkLight
Supported Features
- Updated on 15 Jan 2024
- Print
- DarkLight
The following features are supported in the latest AWS Lambda Edge enforcer (Version 3.2.0)
Additional Activity Handler
The additional activity handler is a callback function passed to the enforcer. The enforcer runs this callback after sending page_requested
or 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.
Advanced Blocking Response (ABR)
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.
Additional S2S Activity
As part of HUMAN Credential Intelligence, this activity informs HUMAN whether the attempted login at a configured login extraction endpoint was successful or not, in addition to other metadata about the login action. The sending of this activity can be configured to be automatic or it can be sent manually as an XHR POST request directly to HUMAN.
Batched Activities
Every request that goes through the enforcer, whether ultimately blocked or passed, is reported to HUMAN backend servers through asynchronous activities. To optimize performance, it is advised to send activities in batches. A batch of activities is sent when the buffer is full or after a fixed time had passed.
Block Page Captcha
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.
Block Page Hard Block
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.
Block Page Rate Limit
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).
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.
Client IP Extraction
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.
Cors Support
Support for cross-origin requests by the Enforcer, this will prevent allowed cross-origin requests from getting blocked by browsers.
CSP Support
Enabling csp_support
protects from cross-site scripting attacks, code injection 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.
CSS Ref
Provides a way to include an additional custom .css file to add to the block page.
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).
Credentials Intelligence
Enables HUMAN to extract credentials from incoming requests and flag credentials that have been compromised. This includes a suite of various configurations and requires access to the HTTP request and response bodies.
Custom Cookie Header
Allows to set a header name which is used to extract the HUMAN 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.
Custom Parameters
This feature enriches activities sent from the enforcer to HUMAN with additional custom data. This data can include user information, session IDs, or other data that HUMAN 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.
Custom Proxy
Defines a proxy server that the enforcer uses for every request to the HUMAN backend service.
Custom Request Handler
Allows for defining a custom JavaScript function that adds a custom response handler to the request.
Custom First Party Path
When set, this will modify all first-party endpoints to use the configured prefix rather than the default prefix.
For example, an application with App ID PX12345678
will have a default first-party sensor endpoint of /12345678/init.js
and a block script endpoint of /12345678/captcha/captcha.js
. If a custom value /botdefense
is configured, the sensor
endpoint will change to /botdefense/init.js
, and the captcha endpoint will change to /botdefense/captcha/captcha.js
.
The value should start with a slash and have no trailing slash.
If you would like to continue supporting the default first party paths as well as the customized ones, you must have two separate CloudFront behaviors: one for the customized path pattern and one for the default path pattern. Both behaviors should be associated with the same HUMANFirstParty Lambda function.
Enforced Routes
Defines a list of routes (as strings or regular expressions) which should always be enforced with no exceptions.
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 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 User Agent
Filters out requests according to their user agent value, avoiding unnecessary traffic in the enforcer verification flow and reducing operation costs.
Filter By Extension
HUMAN does not enforce static assets such as images and documents. To prevent unnecessary API calls to HUMAN servers and needless computation, the enforcer filters all requests with a valid static file extension.
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 HUMAN sensor from making requests to the HUMAN backends, which greatly limits HUMAN's detection capabilities. To avoid this problem, first_party
enables the enforcer to be used as a proxy for HUMAN servers, and to serve content to the browser from a first party endpoint (i.e., an endpoint on the customer’s domain).
GraphQL Detection Enhancement
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 HUMAN to look into the payload of the GraphQL request and retrieve valuable information to enhance our detections, including the operation name & type.
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.
Logger
Enforcers record logs when fatal errors occur during the run of the program. All other errors and messages are logged only when the enforcer is in debug mode. When px_logger_severity
is set to debug mode, the enforcer will output all additional messages to the logger.
Mobile Support
The enforcer recognizes and handles requests coming from HUMAN Mobile SDK. Because mobile apps do not add cookies as part of the HTTP requests, the HUMAN 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.
Module Enable
This feature serves as an on/off switch for the entire module, providing a way to enable and disable all HUMAN 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 HUMAN, even when the enforcer is in active blocking mode.
HUMANDE Cookie
The HUMAN data enrichment (HUMANDE) cookie is a way to transfer additional data between the enforcer and the HUMAN backend servers. The data it contains is set by the HUMAN backend according to the settings in the portal and is available on the cookie as a JSON object.
Sensitive GraphQL Operations
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.
Sensitive Headers
The HUMAN 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 HUMAN backend. Configuring these header names as sensitive headers will remove these headers from requests sent to other backends by HUMAN.
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.
Telemetry Command
The enforcer_telemetry
activity is sent to HUMAN servers whenever the enforcer receives a telemetry command. This activity provides information directly to HUMAN about the current environment and configuration of the enforcer.
VID Extraction
The visitor ID (VID) is an identifier used by HUMAN to identify clients during and across sessions. The VID is crucial for detection, and any mishandling of this feature could decrease its accuracy.
User Identifiers
The User Identifiers are used by HUMAN 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 metadata 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 pxcts cookie.
Decoding URL reserved characters
Enforcers should always ensure that all alphanumeric and unreserved characters are decoded prior to processing the request URL.
However, reserved characters (such as %3F
/ ?
and %2F
/ /
) are left encoded when part of the URL path because they have a special meaning.
In other words, the URIs /login%3F.ico
and /login?.ico
are not equivalent and should not be considered equivalent.
Some servers, frameworks, or business logic may apply percent decoding to reserved characters within the URL path.
Setting this configuration to true will apply decoding to reserved characters in the URL path at the very beginning of the enforcer flow - prior to checking for first party, filtering configurations, and telemetry.
Default: false
const config: HumanSecurityConfiguration = {
// ...
px_url_decode_reserved_characters: true,
// ...
}