> This page is for Applications Protection. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.humansecurity.com/llms.txt. # AWS Lambda@Edge v4 configuration options Each Enforcer has a set of **configuration options** that control the Enforcer's functionality and features. While some are required, many of these are optional configurations that you can use to customize the Enforcer's behavior. You can reference available configurations with this article. You can update and maintain configurations with the [Deploy Tool](/applications/general/deploy-tool#customize-an-enforcer), or you can update directly in the `HumanSecurityConfiguration` object within the Enforcer. > **Note** > > While all Enforcers come with the same set of required configurations, the optional configurations available for each may differ. We recommend updating to the latest Enforcer version to ensure you have access to the latest features and configurations. ## Secrets management For security reasons, we recommend storing sensitive values such as the [cookie secret](#px_cookie_secret) and [authentication token](#px_auth_token) using [AWS Secrets Manager](https://aws.amazon.com/blogs/networking-and-content-delivery/securing-and-accessing-secrets-from-lambdaedge-using-aws-secrets-manager/) rather than hardcoding them. Because retrieving secrets from the AWS Secrets Manager is asynchronous, it can only be done within the handler function. Given a `getConfigAsync` function that returns a Promise resolving to a `HumanSecurityConfiguration` object, you can implement this behavior in your Lambda function: ```ts // index.ts import { CloudFrontRequest, CloudFrontRequestEvent, CloudFrontResponseResult, Context } from 'aws-lambda'; import { HumanSecurityEnforcer } from '@humansecurity/aws-lambda-edge-enforcer'; import { getConfigAsync } from './config'; // initialize the enforcer variable without a value let enforcer; // define a handler export async function handler( event: CloudFrontRequestEvent, context: Context ): Promise { // first, if the enforcer has not been initialized if (!enforcer) { // retrieve and await the configuration const config = await getConfigAsync(); // initialize the enforcer enforcer = HumanSecurityEnforcer.initialize(config); } // the rest is the same logic as the default handler const request = event.Records[0].cf.request; const result = await enforcer.enforce(request, context); if (result) { return result; } // custom logic here return request; } ``` ## Quick reference #### Basic functionality | Feature name | Key | Type | Default | Description | | :----------------------------------------------------------- | :------------------------------ | :------ | :------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Application ID](#px_app_id) | `px_app_id` | String | `""` | HUMAN Application ID | | [Authentication token](#px_auth_token) | `px_auth_token` | String | `""` | HUMAN authentication token | | [Cookie secret](#px_cookie_secret) | `px_cookie_secret` | String | `""` | HUMAN cookie secret | | [Backend domain](#px_backend_url) | `px_backend_url` | String | `https://sapi-.perimeterx.net` | Domain to which HUMAN requests are sent. Derived from your Application ID (lowercase) when unset. | | [S2S timeout](#px_s2s_timeout) | `px_s2s_timeout` | Integer | `1000` | Total time, in milliseconds, that the Enforcer will wait for the Risk API request to return before timing out and passing the request | | [Blocking score](#px_blocking_score) | `px_blocking_score` | Integer | `100` | 0-100. The minimum risk score that the Enforcer blocks from. | | [Max user agent length](#px_user_agent_max_length) | `px_user_agent_max_length` | Integer | `8528` | Maximum length of a user agent. The default value is the current value used by the Collector to truncate the user agent. This configuration should only be modified if it's also modified in the Collector | | [Max risk cookie length](#px_risk_cookie_max_length) | `px_risk_cookie_max_length` | Integer | `2048` | Maximum length of a risk cookie. The default value is the current value used by the Collector to truncate the risk cookie. This configuration should only be modified if it's also modified in the Collector | | [Min risk cookie iterations](#px_risk_cookie_min_iterations) | `px_risk_cookie_min_iterations` | Integer | `500` | Minimum number of iterations for the risk cookie V3. | | [Max risk cookie iterations](#px_risk_cookie_max_iterations) | `px_risk_cookie_max_iterations` | Integer | `5000` | Maximum number of iterations for the risk cookie V3. | #### Basic features | Feature name | Key | Type | Default | Description | | :------------------------------------- | :------------------- | :--------------- | :---------- | :----------------------------------------------------------------------------------------------------------------------------------------- | | [Logger](#px_logger_severity) | `px_logger_severity` | String | `"error"` | The threshold above which logs on a particular event are received. | | [Client IP extraction](#px_ip_headers) | `px_ip_headers` | Array of strings | `[]` | Header names that are trusted to contain the true client IP. This is required when there are proxies between the Enforcer and your server. | | [Module enable](#px_module_enabled) | `px_module_enabled` | Boolean | `true` | Whether the HUMAN Enforcer module is enabled | | [Module mode](#px_module_mode) | `px_module_mode` | String | `"monitor"` | The HUMAN Enforcer's operation mode | #### Optional | Feature name | Key | Type | Default | Description | | :--------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------- | :--------------------------- | :--------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Additional activity handler](#additional-activity-handler) | [`px_additional_activity_handler`](#px_additional_activity_handler) | Function | `null` | The function to invoke after the async activity (`page_requested` or `block`) is sent to the HUMAN backend after enforcement. | | [Advanced blocking response (ABR)](#advanced-blocking-response-abr) | [`px_advanced_blocking_response_enabled`](#px_advanced_blocking_response_enabled) | Boolean | `true` | Whether the ABR feature is enabled. | | [Bypass monitor header](#bypass-monitor-header) | [`px_bypass_monitor_header`](#px_bypass_monitor_header) | String | `"x-px-block"` | The header name to trigger Enforcer blocking workflow even in [monitor mode](#px_module_mode). | | [Credentials Intelligence](#credentials-intelligence) | [`px_login_credentials_extraction_enabled`](#px_login_credentials_extraction_enabled) | Boolean | `false` | Whether to enable Credential Intelligence. | | [Credentials Intelligence](#credentials-intelligence) | [`px_login_credentials_extraction`](#px_login_credentials_extraction) | Array | `[]` | An array of configuration objects for each credential endpoint. See [details](#px_login_credentials_extraction) for more information. | | [Credentials Intelligence](#credentials-intelligence) | [`px_compromised_credentials_header`](#px_compromised_credentials_header) | String | `"px-compromised-credentials"` | The header name to set on the incoming request when credentials are compromised. | | [Credentials Intelligence](#credentials-intelligence) | [`px_automatic_additional_s2s_activity_enabled`](#px_automatic_additional_s2s_activity_enabled) | Boolean | `false` | Whether to send the `additional_s2s` activity automatically in the `postEnforce` function after the origin response is received. | | [Credentials Intelligence](#credentials-intelligence) | [`px_additional_s2s_activity_header_enabled`](#px_additional_s2s_activity_header_enabled) | Boolean | `false` | Whether to attach the `additional_s2s` payload and URL as headers to the original request. This should only be enabled if the [`additional_s2s`](#px_automatic_additional_s2s_activity_enabled) activity isn't sent automatically. | | [Credentials Intelligence](#credentials-intelligence) | [`px_send_raw_username_on_additional_s2s_activity`](#px_send_raw_username_on_additional_s2s_activity) | Boolean | `false` | Whether to send the raw username on the `additional_s2s` activity. | | [CORS support](#cors-support) | [`px_cors_support_enabled`](#px_cors_support_enabled) | Boolean | `false` | Whether to enable CORS support. | | [CORS support](#cors-support) | [`px_cors_create_custom_block_response_headers`](#px_cors_create_custom_block_response_headers) | Function | null | Function to receive the original request and return an object with the custom headers to add to the block response. | | [CORS support](#cors-support) | [`px_cors_preflight_request_filter_enabled`](#px_cors_preflight_request_filter_enabled) | Boolean | `false` | Whether to filter preflight requests that pass the [`px_cors_custom_preflight_handler`](#px_cors_custom_preflight_handler) from the Enforcer. | | [CORS support](#cors-support) | [`px_cors_custom_preflight_handler`](#px_cors_custom_preflight_handler) | Function | null | Preflight requests handler that returns the response before reaching the Enforcer. | | [Custom cookie header](#custom-cookie-header) | [`px_custom_cookie_header`](#px_custom_cookie_header) | String | `"x-px-cookies"` | A custom name for the header that contains HUMAN's cookies | | [Custom first party endpoints](#custom-first-party-endpoints) | [`px_first_party_enabled`](#px_first_party_enabled) | Boolean | `true` | Whether to enable first party mode. | | [Custom first party endpoints](#custom-first-party-endpoints) | [`px_custom_first_party_prefix`](#px_custom_first_party_prefix) | String | `""` | A custom general prefix for each first party resource that routes the entire first party flow to a custom routing. | | [Custom first party endpoints](#custom-first-party-endpoints) | [`px_custom_first_party_sensor_endpoint`](#px_custom_first_party_sensor_endpoint) | String | `""` | A unique, customized endpoint for the first party Sensor. | | [Custom first party endpoints](#custom-first-party-endpoints) | [`px_custom_first_party_xhr_endpoint`](#px_custom_first_party_xhr_endpoint) | String | `""` | A unique, customized endpoint for first party XHR requests. | | [Custom first party endpoints](#custom-first-party-endpoints) | [`px_custom_first_party_captcha_endpoint`](#px_custom_first_party_captcha_endpoint) | String | `""` | A unique, customized endpoint for first party CAPTCHA requests. | | [Custom first party endpoints](#custom-first-party-endpoints) | [`px_first_party_timeout_ms`](#px_first_party_timeout_ms) | Integer | `4000` | The maximum time in milliseconds to wait for first party requests | | [Custom parameters](#custom-parameters) | [`px_enrich_custom_parameters`](#px_enrich_custom_parameters) | Function | `null` | A custom function that accepts the configuration and request objects and returns a map of custom parameters to add to HUMAN activities. | | [Enforced routes](#enforced-routes) | [`px_enforced_routes`](#px_enforced_routes) | Array of strings or `RegExp` | `[]` | An array of regex routes or prefixes that should be enforced even in [monitor mode](#px_module_mode). | | [Enforced routes](#enforced-routes) | [`px_custom_is_enforced_request`](#px_custom_is_enforced_request) | Function | null | A custom function that accepts the request object and returns a boolean indicating whether the request should be enforced. | | [Filters](#filters) | [`px_filter_by_extension`](#px_filter_by_extension) | Array of strings | All common file extensions. See [details](#px_filter_by_extension) for more information. | An array of file extensions that should be ignored by the Enforcer. | | [Filters](#filters) | [`px_filter_by_http_method`](#px_filter_by_http_method) | Array of strings | `[]` | An array of HTTP methods that should be ignored by the Enforcer. | | [Filters](#filters) | [`px_filter_by_ip`](#px_filter_by_ip) | Array of strings | `[]` | An array of IP addresses or CIDR ranges that should be ignored by the Enforcer. | | [Filters](#filters) | [`px_filter_by_route`](#px_filter_by_route) | Array of strings or `RegExp` | `[]` | An array of routes or prefixes that should be ignored by the Enforcer. | | [Filters](#filters) | [`px_filter_by_user_agent`](#px_filter_by_user_agent) | Array of strings or `RegExp` | `[]` | An array of user agents that should be ignored by the Enforcer. | | [Filters](#filters) | [`px_custom_is_filtered_request`](#px_custom_is_filtered_request) | Function | null | A custom function that accepts the request object and returns a boolean indicating whether the request should be filtered. | | [GraphQL support](#graphql-support) | [`px_graphql_enabled`](#px_graphql_enabled) | Boolean | `true` | Whether to extract GraphQL operation data from requests that match [GraphQL routes](#px_graphql_routes). | | [GraphQL support](#graphql-support) | [`px_graphql_routes`](#px_graphql_routes) | Array of strings or `RegExp` | `["/graphql"]` | Path prefixes or patterns to enable GraphQL support on. | | [GraphQL support](#graphql-support) | [`px_sensitive_graphql_operation_names`](#px_sensitive_graphql_operation_names) | Array of strings or `RegExp` | `[]` | Operation names and keywords to trigger the Risk API for regardless of cookies. | | [GraphQL support](#graphql-support) | [`px_sensitive_graphql_operation_types`](#px_sensitive_graphql_operation_types) | Array of strings | `[]` | Operation types to trigger the Risk API for regardless of cookies. | | [GraphQL support](#graphql-support) | [`px_graphql_keywords`](#px_graphql_keywords) | Array of strings or `RegExp` | `[]` | An array of strings or regular expressions. | | [GraphQL support](#graphql-support) | [`px_extract_graphql_keywords`](#px_extract_graphql_keywords) | Function | null | A function that accepts the query and returns an array of keywords. | | [Header data enrichment](#header-data-enrichment) | [`px_data_enrichment_header_name`](#px_data_enrichment_header_name) | String | `""` | The header name to use for sending [data classification enrichment](/applications/data-classification-enrichment) values to the request. | | [HUMAN Challenge & hard block customization](#human-challenge--hard-block-customization) | [`px_css_ref`](#px_css_ref) | String | `""` | A URL to a custom CSS file to customize the [HUMAN Challenge](/applications/customize-challenge-look-feel) and hard block page. | | [HUMAN Challenge & hard block customization](#human-challenge--hard-block-customization) | [`px_js_ref`](#px_js_ref) | String | `""` | A URL to a custom JavaScript file to load with the block page. | | [HUMAN Challenge & hard block customization](#human-challenge--hard-block-customization) | [`px_custom_logo`](#px_custom_logo) | String | `""` | The URL of a custom logo to display on the block page | | [HUMAN Challenge & hard block customization](#human-challenge--hard-block-customization) | [`px_custom_block_on_error_message`](#px_custom_block_on_error_message) | String | `""` | A custom message to display on the block page when an error occurs. | | [Monitored routes](#monitored-routes) | [`px_monitored_routes`](#px_monitored_routes) | Array of strings or `RegExp` | `[]` | Routes that behave as if the Enforcer is in [monitor mode](#px_module_mode) even when actively blocking. | | [Monitored routes](#monitored-routes) | [`px_custom_is_monitored_request`](#px_custom_is_monitored_request) | Function | null | Custom function that returns whether the request should be treated as monitored. | | [PXHD cookie](#pxhd-cookie) | [`px_secured_pxhd_enabled`](#px_secured_pxhd_enabled) | Boolean | `false` | Whether the [`_pxhd` cookie](/applications/use-of-cookies-web-storage) should include the `Secure` attribute. | | [Remote Configuration](#remote-configuration) | [`px_logger_auth_token`](#px_logger_auth_token) | String | `""` | Authentication token for HUMAN's logger service for specific headers. | | [Remote Configuration](#remote-configuration) | [`px_remote_config_auth_token`](#px_remote_config_auth_token) | String | `""` | The Remote Configuration JWT that authenticates with HUMAN's Remote Configuration service. | | [Remote Configuration](#remote-configuration) | [`px_remote_config_id`](#px_remote_config_id) | String | `""` | The Remote Configuration ID. | | [Response custom parameters](#response-custom-parameters) | [`px_enrich_response_custom_parameters`](#px_enrich_response_custom_parameters) | Function | `null` | A custom function that accepts the configuration and response objects and returns a map of custom parameters to add to HUMAN async activities. | | [Sensitive headers removal](#sensitive-headers-removal) | [`px_sensitive_headers`](#px_sensitive_headers) | Array of strings | `["cookie", "cookies"]` | Requests with the specified headers will be considered sensitive and removed from requests sent by the Enforcer. | | [Sensitive routes](#sensitive-routes) | [`px_sensitive_routes`](#px_sensitive_routes) | Array of strings or `RegExp` | `[]` | Routes that the Enforcer will always trigger a Risk API call for. | | [Sensitive routes](#sensitive-routes) | [`px_custom_is_sensitive_request`](#px_custom_is_sensitive_request) | Function | null | Custom function that returns whether the request should be treated as a sensitive route. | | [URL-Decode reserved characters](#url-decode-reserved-characters) | [`px_url_decode_reserved_characters`](#px_url_decode_reserved_characters) | Boolean | `false` | Whether the Enforcer should decode reserved URL characters and reparse the request URL prior to processing. | | [Users identifiers](#users-identifiers) | [`px_jwt_cookie_name`](#px_jwt_cookie_name) | String | `""` | Name of the cookie that contains the JWT token. | | [Users identifiers](#users-identifiers) | [`px_jwt_cookie_user_id_field_name`](#px_jwt_cookie_user_id_field_name) | String | `""` | Name of the field's path that contains the user ID. | | [Users identifiers](#users-identifiers) | [`px_jwt_cookie_additional_field_names`](#px_jwt_cookie_additional_field_names) | Array of strings | `[]` | Additional field paths to extract from the JWT cookie. | | [Users identifiers](#users-identifiers) | [`px_jwt_header_name`](#px_jwt_header_name) | String | `""` | Name of the header that contains the JWT token. | | [Users identifiers](#users-identifiers) | [`px_jwt_header_user_id_field_name`](#px_jwt_header_user_id_field_name) | String | `""` | Name of the field path that contains the user ID. Extracted from the header. | | [Users identifiers](#users-identifiers) | [`px_jwt_header_additional_field_names`](#px_jwt_header_additional_field_names) | Array of strings | `[]` | Additional JWT fields to extract from the header. | | [MCP protection](#mcp-protection) | [`px_agentic_trust_enabled`](#px_agentic_trust_enabled) | Boolean | `false` | Whether MCP protection is enabled. | | [MCP protection](#mcp-protection) | [`px_agentic_trust_mcp_endpoint_path`](#px_agentic_trust_mcp_endpoint_path) | String | `"/mcp"` | The path prefix for MCP endpoint requests. | | [Mobile support](#mobile-support) | [`px_token_version`](#px_token_version) | String | `"3"` | The risk cookie token version to use. | ## Required configurations These configurations are necessary for the Enforcer's basic functionality and features. ### Basic functionality configurations **`px_app_id`** `string` — required Your HUMAN Application ID in the form of `PX12AB34CD`. You can copy this value from the [HUMAN Console](https://console.humansecurity.com/) in **Platform Settings > Applications Overview.** If you have multiple applications, make sure to copy the ID of the application you want the Enforcer on. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_app_id: '', // ... } ``` --- **`px_auth_token`** `string` — required The application's server token needed to authorize with HUMAN's backend. You can copy this value from the [HUMAN Console](https://console.humansecurity.com/) in **Platform Settings > Applications Overview > Click the appropriate application > Server token tab.** **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_auth_token: '', // ... } ``` --- **`px_cookie_secret`** `string | string[]` — required The secret used to encrypt and decrypt the risk cookie sent from the HUMAN Sensor. You can copy this value from the [HUMAN Console](https://console.humansecurity.com/) in **Sightline Cyberfraud Defense > Traffic Policy Overview > Click the appropriate application > Click the key > Copy value.** If you need to rotate secrets, then adjust this configuration to be an array of strings (`string[]`) and include the new secret and old secret. The new secret value should be the first value in the array. This prevents decryption failures. **`Basic example`** ```ts Basic example const config: HumanSecurityConfiguration = { // ... px_cookie_secret: '', // ... } ``` **`Cookie rotation example`** ```ts Cookie rotation example const config: HumanSecurityConfiguration = { // ... px_cookie_secret: ['', ''], // ... } ``` --- **`px_s2s_timeout`** `integer` — required, default: 1000 The total time in milliseconds that the Enforcer will wait for the **Risk API** request to return before timing out and passing the request. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_s2s_timeout: 2000, // ... } ``` --- **`px_blocking_score`** `integer` — default: 100 The minimum risk score that the Enforcer will block. Ranges from 0 (lowest risk) to 100 (highest risk). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_blocking_score: 20, // ... } ``` --- **`px_user_agent_max_length`** `integer` — default: 8528 > **Warning** > > Do not modify this value without consulting your HUMAN Solutions Engineer. The maximum length of the `User-Agent` header. If the user agent header value exceeds this length, it will be truncated to this length prior to processing. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_user_agent_max_length: 2048, // ... } ``` --- **`px_risk_cookie_max_length`** `integer` — default: 2048 The maximum length of the risk cookie. If the value exceeds this length, then validation will fail automatically. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_risk_cookie_max_length: 2048, // ... } ``` --- **`px_risk_cookie_min_iterations`** `integer` — default: 500 The minimum accepted number of iterations for the Risk Cookie V3. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_risk_cookie_min_iterations: 500, // ... } ``` --- **`px_risk_cookie_max_iterations`** `integer` — default: 5000 The maximum accepted number of iterations for the Risk Cookie V3. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_risk_cookie_max_iterations: 5000, // ... } ``` --- ### Basic feature configurations **`px_logger_severity`** `"none" | "error" | "debug"` — default: "error" The severity at which the logger will output logs. * `none`: The logger will not generate any logs. * `error`: The logger will only generate logs on fatal errors. * `debug`: The logger will generate detailed logs for debugging purposes. Not recommended for production environments. See [`px_logger_auth_token`](#px_logger_auth_token) for a header-based alternative. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_logger_severity: 'debug', // ... } ``` --- **`px_ip_headers`** `string[]` — default: \[] An array of header names that are trusted to contain the true client IP. Headers are traversed in the order they're listed, and the first header value will always be used as the client IP. Taken from [request.clientIp request property](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) by default. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_ip_headers: ['true-ip', 'true-client-ip'], // ... } ``` --- **`px_module_enabled`** `boolean` — default: true Whether the Enforcer module is enabled. * `true`: Enable the module * `false`: Disable the module **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_module_enabled: false, // ... } ``` --- **`px_module_mode`** `"monitor" | "active_blocking"` — default: monitor The Enforcer's operation mode. * `monitor`: The Enforcer performs all functions without returning block responses. Useful for analyzing and adjusting Enforcer behavior without serving block pages to end users. If you have routes that must have enforcement at all times, see [Enforced routes](#enforced-routes). * `active_blocking`: The Enforcer will return block responses as needed. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_module_mode: 'active_blocking', // ... } ``` --- ## Optional configurations These configurations aren't required, but you can use them to further customize the Enforcer's behavior. ### Additional activity handler **`px_additional_activity_handler`** `function` — default: null A custom function passed to the Enforcer that runs 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 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. **Parameters:** * `config: HumanSecurityConfiguration` * `context: IContext` * `request:` [CloudFrontRequest](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) **Returns:** `void` or a Promise resolving to `void` **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_additional_activity_handler: ( config: HumanSecurityConfiguration, context: IContext, request: CloudFrontRequest ): void => { request.headers['x-px-score'] = [{ key: 'x-px-score', value: '' + context.score }]; request.headers['x-px-rtt'] = [{ key: 'x-px-rtt', value: '' + context.riskApiData.riskRtt }]; }, // ... } ``` --- ### Advanced blocking response (ABR) **`px_advanced_blocking_response_enabled`** `boolean` — default: true In specific cases such as XHR post requests, a full CAPTCHA page render might not be an option. In such cases, the [Advanced Blocking Response (ABR)](/applications/set-challenge-configurations#enable-challenge-configurations#custom-abr) returns a JSON object containing all the information needed to render a customized CAPTCHA challenge implementation such as a popup modal, a section on the page, etc. This provides more flexibility and customizability in displaying the CAPTCHA challenge. * `true`: Enable ABR * `false`: Disable ABR **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_advanced_blocking_response_enabled: false, // ... } ``` --- ### Bypass monitor header **`px_bypass_monitor_header`** `string` — default: x-px-block Activates the full blocking flow to verify the flow works as expected if the specified header is present on the request with a value of `1`. Often used to test the Enforcer block workflow during [monitor mode](#px_module_mode), where the Enforcer usually collects data without blocking user requests, before switching to `active_blocking`. Requests with this header will go through the entire blocking workflow despite being in monitor mode. To disable blocking behavior on the specified header, set the value to `0`. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_bypass_monitor_header: 'human-block', // ... } ``` --- ### Credentials Intelligence These configurations let you extract and detect compromised credentials. They're closely related to [Credentials Intelligence-related features](/applications/about-the-credentials-intelligence-dashboard) in Sightline Cyberfraud Defense. At minimum, ensure the following are configured to enable Credential Intelligence: * [`px_login_credentials_extraction_enabled`](#px_login_credentials_extraction_enabled) is set to `true` * [`px_login_credentials_extraction`](#px_login_credentials_extraction) is configured with at least one credential endpoint **`px_login_credentials_extraction_enabled`** `boolean` — default: false Whether to enable the extraction and reporting of credentials from the Enforcer for Credential Intelligence. * `true`: Enable Credential Intelligence * `false`: Disable Credential Intelligence **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_login_credentials_extraction_enabled: true, // ... } ``` --- **`px_login_credentials_extraction`** `array` An array of configuration objects for each credential endpoint. Each element in the array is an object representing a distinct endpoint to which credentials are sent and includes: * How to identify these credential-bearing requests * How to extract the credentials from the request * How to determine if the request operation (login, signup, etc.) was successful based on the returned HTTP response Click to expand the full properties list. #### Properties **`path`** `string` — required The path of the request that contains the credentials. It can be either an exact path or a string in the form of a regular expression. **`Example`** ```json Example { // ... path: '/sign-up', // ... } ``` --- **`path_type`** `"exact" | "regex"` — default: "exact" Whether the incoming request path should be evaluated against the configured path as a regular expression or as an exact match. * `exact`: The value set in `path` must match the request path exactly as is. * `regex`: The value set in `path` is a regular expression to be matched against the request path. **`Example`** ```json Example { // ... path: '/auth/[A-Za-z0-9]{12}/login', path_type: 'regex', // ... } ``` --- **`method`** `string` — required The HTTP method of the request that contains the credentials. This can be set to any string representing an HTTP method. **`Example`** ```json Example { // ... method: 'POST', // ... } ``` --- **`sent_through`** `"body" | "header" | "query-param" | "custom"` — required Whether the credentials should be extracted from the request headers, query parameters, body, or via a defined custom callback. * `"body"`: The credentials will be extracted according to the configured [`user_field`](#user_field) and [`pass_field`](#pass_field) values from the request body. The Enforcer parses the request body based on the following `Content-Type` request header: * `application/json` * `application/x-www-form-urlencoded` * `multipart/form-data` * `"header"`: The credentials will be extracted according to the configured [`user_field`](#user_field) and [`pass_field`](#pass_field) values from the request headers. * `"query-param"`: The credentials will be extracted according to the configured [`user_field`](#user_field) and [`pass_field`](#pass_field) values from the request query parameters. * `"custom"`: The credentials will be extracted by invoking [`extract_credentials_callback`](#extract_credentials_callback). **`Example`** ```json Example { // ... sent_through: 'body', // ... } ``` --- **`user_field`** `string` **Required** if [`sent_through`](#sent_through) is set to `"body"`, `"header"`, or `"query-param"`. The name of the field containing the username in the request body, headers, or query parameters. Supports subfields in cases of `Content-Type: application/json` bodies with nested objects. The subfields can be separated with periods. For example, the credential endpoint configuration object can include a `user_field` with the value `"user_info.username"` and a `pass_field` with the value `"authentication.password"` to support extracting the credentials. **`Basic example`** ```json Basic example { // ... sent_through: 'body', user_field: 'username', // ... } ``` **`Subfields example`** ```json Subfields example { "user_info": { "username": "user123" }, "authentication": { "password": "P@s$w0rD!" } } ``` --- **`pass_field`** `string` **Required** if [`sent_through`](#sent_through) is set to `"body"`, `"header"`, or `"query-param"`. The name of the field, header name, or query parameter where the password can be found. Supports subfields in cases of `Content-Type: application/json` bodies with nested objects. The subfields can be separated with periods. For example, the credential endpoint configuration object can include a `user_field` with the value `"user_info.username"` and a `pass_field` with the value `"authentication.password"` to support extracting the credentials. **`Basic example`** ```json Basic example { // ... sent_through: 'body', user_field: 'username', // ... } ``` **`Subfields example`** ```json Subfields example { "user_info": { "username": "user123" }, "authentication": { "password": "P@s$w0rD!" } } ``` --- **`extract_credentials_callback`** `function` **Required** if [`sent_through`](#sent_through) is set to `"custom"`. A custom credential extraction callback that returns the raw credentials from the request. It receives the HTTP request as a parameter and should return a Credentials object: **`Credentials object example`** ```json Credentials object example type Credentials = { user?: string; // the raw username pass?: string; // the raw password }; ``` **Parameters:** * `request:` [CloudFrontRequest](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) **Returns:** A Credentials object or a Promise resolving to a Credentials object. If neither the username or the password can be extracted from the request, the function should return `null`. **`Example`** ```ts Example { // ... sent_through: 'custom', extract_credentials_callback: async (request: CloudFrontRequest): Promise => { if (!request.body?.data) return {}; // ... // custom extraction resulting in username and password // ... if (!username || !password) { // unsuccessful extraction return {}; } // successfully extracted credentials return { user: username, pass: password }; }, // ... } ``` --- **`protocol`** `"v2" | "multistep_sso" | "both"` — default: "both" Whether to process credentials as part of single or multiple HTTP requests. By default, the module tries to process requests depending on which credential fields were extracted. * `"v2"`: Both username and password are present on the same HTTP request and must be extracted successfully to trigger Credential Intelligence. * `"multistep_sso"`: The username and password are delivered on different HTTP requests. Either the username or password, but not both, must be extracted successfully to trigger Credential Intelligence. * `"both"`: The username and password may be present on the same HTTP request or on different HTTP requests. If either username or password is successfully extracted, the Enforcer will send the credentials according to the multistep\_sso protocol. If both username and password are successfully extracted, the Enforcer will send the credentials according to the v2 protocol. **`Example`** ```ts Example { // ... protocol: 'v2', // ... } ``` --- **`login_successful_reporting_method`** `"status" | "body" | "header" | "custom"` — required, default: status The method by which the Enforcer will determine whether the login request was successful. * `"status"`: The Enforcer will determine if the login request was successful by evaluating the response status code against the [`login_successful_statuses`](#login_successful_statuses) configuration. * `"body"`: The Enforcer will determine if the login request was successful by evaluating the response body content against the [`login_successful_body_regex`](#login_successful_body_regex) configuration. * `"header"`: The Enforcer will determine if the login request was successful by evaluating the response headers against the [`login_successful_header_name`](#login_successful_header_name) and [`login_successful_header_value`](#login_successful_header_value) configurations. * `"custom"`: The Enforcer will determine if the login request was successful by invoking [`login_successful_callback`](#login_successful_callback). **`Example`** ```ts Example { // ... login_successful_reporting_method: 'status', // ... } ``` --- **`login_successful_statuses`** `integer[]` — default: \[200] An array of HTTP statuses signifying a successful login. All other status codes will be treated as unsuccessful login attempts. Takes effect only when the [`login_successful_reporting_method`](#login_successful_reporting_method) is set to `"status"`. **`Example`** ```ts Example { // ... login_successful_reporting_method: 'status', login_successful_statuses: [200, 202], // ... } ``` --- **`login_successful_header_name`** `string` **Required** if [`login_successful_reporting_method`](#login_successful_reporting_method) is set to `"header"`. A response header name signifying a successful login response. If the [`login_successful_header_value`](#login_successful_header_value) field is empty or not configured, any response containing this header name will be considered a successful login. If the [`login_successful_header_value`](#login_successful_header_value) is configured, the response header value must be an exact match. **`Example`** ```ts Example { // ... login_successful_reporting_method: 'header', login_successful_header_name: 'x-login-successful' // ... } ``` --- **`login_successful_header_value`** `string` If this value is configured, a login attempt will be considered successful only if the response contains a header name matching the [`login_successful_header_name`](#login_successful_header_name), and whose value is exactly equal to this configuration value. Takes effect only when the [`login_successful_reporting_method`](#login_successful_reporting_method) is set to `"header"`. **`Example`** ```ts Example { // ... login_successful_reporting_method: 'header', login_successful_header_name: 'x-user-status', login_successful_header_value: 'logged-in' // ... } ``` --- **`login_successful_callback`** `function` **Required** if [`login_successful_reporting_method`](#login_successful_reporting_method) is set to `"custom"`. A custom callback that accepts the HTTP response and returns a boolean or Promise resolving to a boolean that indicates whether the login attempt was successful. **Parameters:** * `response:` [CloudFrontResultResponse](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-response) **Returns:** A boolean or a Promise resolving to a boolean. **`Example`** ```ts Example { // ... login_successful_reporting_method: 'custom', login_successful_callback: (response: CloudFrontResultResponse): boolean => { return response.status === '200' && response.headers['set-cookie']?.[0]?.value?.includes('session_token='); }, // ... } ``` --- **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_login_credentials_extraction: [ { path: '/auth/[A-Za-z0-9]{12}/login', path_type: 'regex', method: 'POST', sent_through: 'body', user_field: 'username', pass_field: 'password', login_successful_reporting_method: 'status', login_successful_statuses: [200, 202] }, { path: '/sign-up', method: 'POST', sent_through: 'custom', extract_credentials_callback: (request: CloudFrontRequest): Credentials => { // custom implementation resulting in variables username and password if (username && password) { return { "user": username, "pass": password }; } else { return null; } }, login_successful_reporting_method: 'custom', login_successful_callback: (response: CloudFrontResultResponse): boolean => { return response.headers['set-cookie']?.[0]?.value?.includes('session_token='); } }, // ... ], // ... } ``` --- **`px_compromised_credentials_header`** `string` — default: px-compromised-credentials The header name to be set on the incoming request if the credentials are compromised. If this header is added, its value will always be `1`. If credentials have not been identified as compromised, the header will not be added to the request. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_compromised_credentials_header: 'x-ci-compromised', // ... } ``` --- **`px_automatic_additional_s2s_activity_enabled`** `boolean` — default: false > **Warning** > > If you are manually installing the Enforcer, you must [Upload the HumanActivities Lambda](/applications/aws-lambdaedge/v4/manual-installation#upload-the-humanactivities-lambda) to enable this feature. Whether to send the `additional_s2s` activity, which reports on whether the login was successful, automatically in the `postEnforce` function. This should only be set to `false` if it's not possible to determine whether the login was successful based on the HTTP response. However, if that's the case, then the `additional_s2s` activity must be sent with [`px_additional_s2s_activity_header_enabled`](#px_additional_s2s_activity_header_enabled). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_automatic_additional_s2s_activity_enabled: false, // ... } ``` --- **`px_additional_s2s_activity_header_enabled`** `boolean` — default: false Whether to attach the `additional_s2s` payload and URL as headers to the original request. This is done so that the `additional_s2s` activity can be enriched with the proper `login_successful` value and sent to the provided URL at a later stage. This should only be enabled if the [`px_automatic_additional_s2s_activity_enabled`](#px_automatic_additional_s2s_activity_enabled) is set to `false`. When set to `true`, the following headers are added to the origin request: * `px-additional-activity`: A JSON object containing the payload of the `additional_s2s` activity. The `login_successful` and `http_status_code` fields should be set prior to sending the activity. * `px-additional-activity-url`: The URL to which the `additional_s2s` payload should be sent as an HTTP POST request. **`Configuration example`** ```ts Configuration example const config: HumanSecurityConfiguration = { // ... px_additional_s2s_activity_header_enabled: true, // ... } ``` **`Example to handle additional_s2s at the origin`** ```js Example to handle additional_s2s at the origin app.post('/login', (req, res) => { // handle login flow, resulting in variables // isLoginSuccessful (boolean) and responseStatusCode (number) if ( req.headers['px-additional-activity'] && req.headers['px-additional-activity-url'] ) { handlePxAdditionalActivity(req, responseStatusCode, isLoginSuccessful); } }); function handlePxAdditionalActivity(req, statusCode, isLoginSuccessful) { try { // extract url and activity from the request headers const url = req.headers['px-additional-activity-url']; const activity = JSON.parse(req.headers['px-additional-activity']); // enrich the activity details with added information activity.details['http_status_code'] = statusCode; activity.details['login_successful'] = isLoginSuccessful; if (activity.details['credentials_compromised'] && isLoginSuccessful) { // add raw username if credentials are compromised and login is successful (only if desired) activity.details['raw_username'] = req.body.username; } else { // remove raw username if login is not successful or credentials are not compromised delete activity.details['raw_username']; } // send the POST request axios.post(url, activity, { headers: { 'Authorization': `Bearer ${env.PX_AUTH_TOKEN}`, 'Content-Type': 'application/json' } }); } catch (err) { console.error(`Error: ${err}`); } } ``` --- **`px_send_raw_username_on_additional_s2s_activity`** `boolean` — default: false Whether to report the raw username on the `additional_s2s` activity. * `false`: The raw username will never be reported. * `true`: The raw username will only be reported if: * The credentials are compromised, and * The login request was successful. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_send_raw_username_on_additional_s2s_activity: true, // ... } ``` --- ### CORS support You can configure the Enforcer to support Cross-Origin Resource Sharing (CORS) requests. CORS is a mechanism that lets the server indicate if a request contains cross-origin resources by adding special HTTP headers to the request. These headers let the browser load these resources. Without them, the browser may block requests to these resources for security reasons instead. In most cases, CORS employs a two-stage procedure with a preliminary “preflight” request followed by the actual request. The preflight request checks if the actual request will be responded to. To learn more about different request types, see these [examples](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#examples_of_access_control_scenarios). You must configure the Enforcer to address both simple requests (without preflight) and more complex ones (with preflight) to support CORS requests. **`px_cors_support_enabled`** `boolean` — default: false Whether to enable CORS support. * `true`: Enable CORS support * `false`: Disable CORS support After setting this configuration to `true`, the Enforcer: * Automatically adds the following default CORS response headers to block responses resulting from CORS requests. ``` Access-Control-Allow-Origin: Access-Control-Allow-Credentials: true ``` * Activates the [`px_cors_create_custom_block_response_headers`](#px_cors_create_custom_block_response_headers) configuration, which lets you customize the block response headers via a custom function. * Activates the [`px_cors_preflight_request_filter_enabled`](#px_cors_preflight_request_filter_enabled) and [`px_cors_custom_preflight_handler`](#px_cors_custom_preflight_handler) configurations, which lets you filter and custom handle preflight requests. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_cors_support_enabled: true, // ... } ``` --- **`px_cors_create_custom_block_response_headers`** `function` — default: null If the default CORS response headers are not sufficient, you can use this configuration to customize the headers that should be added to all block responses resulting from CORS requests. If this function is defined, the default headers will **not** be added. Only those headers specified in the returned object will be added to the block response. **Parameters:** * `request:` [CloudFrontRequest](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) **Returns:** An object of the type `Record` or a Promise resolving to this type **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_cors_create_custom_block_response_headers: ( request: CloudFrontRequest, ): Record => { return { 'Access-Control-Allow-Origin': [request.headers['origin']?.[0]?.value], 'Access-Control-Allow-Credentials': ['false'], 'Access-Control-Allow-Methods': ['GET', 'POST', 'PUT'], 'X-Custom-Header': ['1'] }; }, // ... } ``` --- **`px_cors_preflight_request_filter_enabled`** `boolean` — default: false Disables enforcement for CORS preflight requests. When set to `true`, CORS preflight requests will be pass through the Enforcer flow without triggering detection or block responses. * `true`: Filter out preflight requests * `false`: Don't filter out preflight requests **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_cors_preflight_request_filter_enabled: true, // ... } ``` --- **`px_cors_custom_preflight_handler`** `function` — default: null A custom function to define desired behavior for handling CORS preflight requests, if needed. The custom function should receive the original HTTP request and return an object representing the HTTP response to be returned. If null or any other falsy value is returned from the function, the Enforcer will continue processing the preflight request. The `px_cors_custom_preflight_handler` will be invoked **prior** to determining whether to filter the request based on the [`px_cors_preflight_request_filter_enabled`](#px_cors_preflight_request_filter_enabled) configuration. This allows for returning customized responses for preflight requests that meet certain conditions and filtering those that don’t meet these conditions. **Parameters:** * `request:` [CloudFrontRequest](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) **Returns:** An object of the type `IMinimalResponse` or a Promise resolving to this type ```ts interface IMinimalResponse { status: number; headers: Record; body: any; }; ``` **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_cors_custom_preflight_handler: (request: CloudFrontRequest): IMinimalResponse | Promise => { const headers = { 'Access-Control-Allow-Origin': [request.headers['origin']?.[0]?.value], 'Access-Control-Allow-Methods': [request.headers['access-control-request-method']?.[0]?.value], 'Access-Control-Allow-Headers': [request.headers['access-control-request-headers']?.[0]?.value], 'Access-Control-Allow-Credentials': ['true'], 'Access-Control-Max-Age': ['86400'] }; return { status: 204, headers, body: null, }; }, // ... } ``` --- ### Custom cookie header **`px_custom_cookie_header`** `string` — default: x-px-cookies By default, the Enforcer extracts HUMAN cookies from the `Cookie` header. However, if these cookies are transferred on a different header, then that header's name must be provided with this configuration. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_cookie_header: 'x-custom-cookies', // ... } ``` --- ### Custom first party endpoints These configurations let you use the Enforcer as a proxy for HUMAN servers and serve content to the browser from a first party endpoint. These are particularly useful when browser or extension restrictions that block JavaScript requests to other domains, such as adblockers, prevent the HUMAN **Sensor** from making requests to HUMAN's backend. When this happens, it significantly limits HUMAN's detection capabilities, so we recommend enabling these configurations to maintain full detection capabilities. > **Warning** > > If you are manually installing the Enforcer, you must [Upload the HumanFirstParty Lambda](/applications/aws-lambdaedge/v4/manual-installation#upload-the-humanfirstparty-lambda) to enable these configurations. **`px_first_party_enabled`** `boolean` — default: true Whether to enable first party mode for Bot Defender or Sightline Cyberfraud Defense. Maps to `{{firstPartyEnabled}}` in the block page template. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_first_party_enabled: false, // ... } ``` --- **`px_custom_first_party_prefix`** `string` Sets a custom prefix for first party routes to use in addition to the default prefix. By default, first party endpoints always begin with the **Application ID** without the initial “PX”. For example, if the ID is `PX12345678`, then all first party routes will take the form `/12345678/*`. When configured, the Enforcer will respond to first party requests with endpoints matching the following patterns: * `//init.js` * `//xhr/*` * `//captcha/*` If empty, the configuration will use the default as described above. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_first_party_prefix: "/custom-prefix", // ... } ``` --- **`px_custom_first_party_sensor_endpoint`** `string` Customizes the entire first party **Sensor** script endpoint. By default, for an Application ID `PX12345678`, the first party endpoint is `/12345678/init.js`. In addition to responding to requests that match this configured route, the Enforcer will also proxy first party requests that match the default pattern (`/12345678/init.js`) and patterns according to the [custom prefix](#px_custom_first_party_prefix) (`//init.js`) if one is configured. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_first_party_sensor_endpoint: "/human_sensor", // ... } ``` --- **`px_custom_first_party_xhr_endpoint`** `string` Customizes the first party XHR endpoint. By default, for an **Application ID** `PX12345678`, the first party XHR endpoint is `/12345678/xhr`. In addition to responding to requests that match this configured route, the Enforcer will also proxy first party requests that match the default pattern (`/12345678/xhr/*`) and patterns according to the [custom prefix](#px_custom_first_party_prefix) (`//xhr/*`) if one is configured. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_first_party_xhr_endpoint: "/human_xhr", // ... } ``` --- **`px_custom_first_party_captcha_endpoint`** `string` Customizes the first party CAPTCHA endpoint. By default, for an **Application ID** `PX12345678`, the first party CAPTCHA endpoint is `/12345678/captcha`. In addition to responding to requests that match this configured route, the Enforcer will also proxy first party requests that match the default pattern (`/12345678/captcha/*`) and patterns according to the [custom prefix](#px_custom_first_party_prefix) (`//captcha/*`) if one is configured. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_first_party_captcha_endpoint: "/human_captcha", // ... } ``` --- **`px_first_party_timeout_ms`** `integer` — default: 4000 The maximum time in milliseconds to wait for first party requests. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_first_party_timeout_ms: 10000, // ... } ``` --- ### Custom parameters These configurations are related to [custom parameters](/applications/set-custom-parameters). **`px_enrich_custom_parameters`** `function` — default: null Enriches activities sent from the Enforcer to HUMAN with additional custom parameters. 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. **Parameters:** * `config: HumanSecurityConfiguration` * `request:` [CloudFrontRequest](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) **Returns:** `Promise` **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_enrich_custom_parameters: async ( config: HumanSecurityConfiguration, request: CloudFrontRequest, ): CustomParameters | Promise => { const body = request.method === 'POST' && request.headers['content-type']?.[0]?.value?.includes('application/json') ? request.body : null; return { custom_param1: 'hardcoded value', custom_param2: request.headers['origin']?.[0]?.value }; }, // ... } ``` --- ### Enforced routes These configurations let you define specific routes that should be enforced by HUMAN when the Enforcer is in [monitor mode](#px_module_mode). These routes will always be subject to the full Enforcer workflow, including blocking requests if necessary. Primitive string values are treated as path prefixes. For example, `/login` also matches `/login/callback`. **`px_enforced_routes`** `array` — default: \[] Routes or prefixes that should be enforced by HUMAN even when the Enforcer is in [monitor mode](#px_module_mode). Supports strings or regular expressions, including regex-formatted strings (for example, `"/^/regex/formatted/string/i"`). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_enforced_routes: ['/enforced_route', /.*\/enforced\/regex$/], // ... } ``` --- **`px_custom_is_enforced_request`** `function` — default: null > **Warning** > > This configuration is meant for cases that require more complex logic. We recommended you use [`px_enforced_routes`](#px_enforced_routes) for most cases. A custom function that lets you define which requests should be enforced based on custom logic. It accepts the incoming request as an argument and returns a boolean indicating whether the request should be enforced. **Parameters:** * `request:` [CloudFrontRequest](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) **Returns:** A boolean or a Promise resolving to a boolean. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_is_enforced_request: (request: CloudFrontRequest): boolean | Promise => { return request.method === 'POST' && request.uri.includes('/enforced_route'); }, // ... } ``` --- ### Filters These configurations let you filter out certain requests or assets from the Enforcer. These values will be ignored by the Enforcer and will never be blocked. **`px_filter_by_extension`** `array of strings` — default: \[ '.css', '.bmp', '.tif', '.ttf', '.docx', '.woff2', '.js', '.pict', '.tiff', '.eot', '.xlsx', '.jpg', '.csv', '.eps', '.woff', '.xls', '.jpeg', '.doc', '.ejs', '.otf', '.pptx', '.gif', '.pdf', '.swf', '.svg', '.ps', '.ico', '.pls', '.midi', '.svgz', '.class', '.png', '.ppt', '.mid', '.webp', '.jar', '.json', '.xml' ] Filters out requests with the specified file extension. By default, HUMAN doesn't enforce static assets such as images and documents to minimize unncessary API calls and computation, but you can configure this list at any time. > **Note** > > Filtering by extension only applies to GET and HEAD HTTP methods. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_filter_by_extension: ['.css', '.js', '.png'], // ... } ``` --- **`px_filter_by_http_method`** `array of strings` — default: \[] Filters out requests with the specified HTTP method to avoid unnecessary traffic in the Enforcer verification flow. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_filter_by_http_method: ['OPTIONS', 'DELETE'], // ... } ``` --- **`px_filter_by_ip`** `array of strings` — default: \[] Filters out requests with the specified IP address to avoid unnecessary traffic in the Enforcer verification flow. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_filter_by_ip: ['1.1.1.1', '2.2.2.2/8'], // ... } ``` --- **`px_filter_by_route`** `array` — default: \[] Filters out requests with the specified route to avoid unnecessary traffic in the Enforcer verification flow. Requests to these specified routes will never be blocked regardless of their **risk score** and will never generate risk or async activities. Primitive string values are treated as path prefixes. For example, `/login` also matches `/login/callback`. Supports strings or regular expressions, including regex-formatted strings (i.e. `"/^/regex/formatted/string/i"`). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_filter_by_route: ['/filtered_route', /.*\/filtered\/regex$/], // ... } ``` --- **`px_filter_by_user_agent`** `array` — default: \[] Filters out requests with the specified user agent to avoid unnecessary traffic in the Enforcer verification flow. Primitive string values are case-sensitive and require an exact user-agent string. Supports strings or regular expressions, including regex-formatted strings (i.e. `"/^/regex/formatted/string/i"`). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_filter_by_user_agent: ['filtered_UA', /.*\/filtered\/regex$/], // ... } ``` --- **`px_custom_is_filtered_request`** `function` — default: null > **Warning** > > This configuration is meant for cases that require more complex logic. We recommended you use the other default filters available for most cases. A custom function that lets you define which requests should be filtered based on custom logic. It accepts the incoming request as an argument and returns a boolean indicating whether the request should be filtered. **Parameters:** * `request:` [CloudFrontRequest](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) **Returns:** A boolean or a Promise resolving to a boolean. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_is_filtered_request: (request: CloudFrontRequest): boolean | Promise => { return request.method === 'GET' && request.uri.includes('/static/'); }, // ... } ``` --- ### GraphQL support These configurations let the Enforcer extract [GraphQL](https://graphql.org/learn/) data from requests so that it can enforce these requests in the same way as other types of traffic. **`px_graphql_enabled`** `boolean` — default: true Whether to parse and report information about GraphQL operations on incoming requests. When `true`, all POST requests with routes that match the prefixes configured in [`px_graphql_routes`](#px_graphql_routes) will have their bodies parsed for GraphQL operations. * `true`: Enable GraphQL support * `false`: Disable GraphQL support **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_graphql_enabled: true, // ... } ``` --- **`px_graphql_routes`** `array` — default: \["/graphql"] A list of regex routes that should be considered GraphQL routes. If a request’s route matches any of the regexes in this list, HUMAN checks for sensitive GraphQL operations as specified in [`px_sensitive_graphql_operation_names`](#px_sensitive_graphql_operation_names) and [`px_sensitive_graphql_operation_types`](#px_sensitive_graphql_operation_types). Supports strings or regular expressions, including regex-formatted strings (i.e. `"/^/regex/formatted/string/i"`). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_graphql_routes: ['/graphql', /^\/\w+\/graphql/], // ... } ``` --- **`px_sensitive_graphql_operation_names`** `array` — default: \[] A list of operation names that should be considered sensitive. Some routes may be more prone to bot attacks than others, such as routes that execute payments or handle personal information. You can configure these routes as sensitive to ensure a more stringent protection. If one or more GraphQL operations has a name or keyword matching this list, the Enforcer will trigger a **Risk API** call even if the request contains a valid, unexpired cookie. Matches against extracted GraphQL words from: * [`px_graphql_keywords`](#px_graphql_keywords) configuration * [`px_extract_graphql_keywords`](#px_extract_graphql_keywords) configuration Supports strings or regular expressions, including regex-formatted strings (i.e. `"/^RegexFormattedString$/i"`). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_sensitive_graphql_operation_names: ['LoginOperation', /sensitiveKeyword/], // ... } ``` --- **`px_sensitive_graphql_operation_types`** `'query' | 'mutation' | 'subscription'` — default: \[] A list of operation types that should be considered sensitive. Some routes may be more prone to bot attacks than others, such as routes that execute payments or handle personal information. You can configure these routes as sensitive to ensure a more stringent protection. If one or more GraphQL operations on an HTTP request has a type matching this list, the Enforcer will trigger a **Risk API** call even if the request contains a valid, unexpired cookie. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_sensitive_graphql_operation_types: ['query', 'mutation'], // ... } ``` --- **`px_graphql_keywords`** `array` — default: \[] A list of keywords to identify important terms from GraphQL operation queries. These keywords are used to determine the purpose of the operation (such as login, checkout, or search) and can also be used to specify which operations should be considered sensitive. Any matching patterns will be extracted and reported to HUMAN. See [`px_sensitive_graphql_operation_names`](#px_sensitive_graphql_operation_names) for more information. See [`px_extract_graphql_keywords`](#px_extract_graphql_keywords) for an alternative using a custom function. Supports strings or regular expressions, including regex-formatted strings (i.e. `"/^RegexFormattedString$/i"`). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_graphql_keywords: ['performLogin', 'addToCart', /keyword\d+/], // ... } ``` --- **`px_extract_graphql_keywords`** `function` — default: null A custom function that identifies key terms from GraphQL operation queries. An alternative to the [`px_graphql_keywords`](#px_graphql_keywords) configuration. This function accepts the GraphQL query string and must return an array of strings representing all keywords found in the query. These keywords are used to determine the purpose of the operation (such as login, checkout, search) and can also be used to specify which GraphQL operations should be considered sensitive. See [`px_sensitive_graphql_operation_names`](#px_sensitive_graphql_operation_names) for more information. If this function is defined and returns an array (even an empty array), then the returned array will be used as the GraphQL keywords. If this function is defined and returns null, then the query will continue to be evaluated using [`px_graphql_keywords`](#px_graphql_keywords). **Parameters:** * `graphqlQuery: string` Returns `string[]` or a Promise resolving to `string[]`. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_extract_graphql_keywords: (graphqlQuery: string): string[] | Promise => { if (/userId\d+/.test(graphqlQuery)) { // report no keywords for this query return []; } else if (/perform(Login|Signin)/.test(graphqlQuery)) { // always report 'login' as the only keyword for this query return ['login']; } else { // process query according to px_graphql_keywords configuration return null; } }, // ... } ``` --- ### Header data enrichment These configurations let you add headers to incoming requests with additional data. **`px_data_enrichment_header_name`** `string` — default: "" Adds a header to the incoming request with the configured header name and the JSON-stringified data enrichment object as the value. If empty or if data enrichment has not been enabled for your policy, no header will be set. To view available data and enable this feature, see [Data classification enrichment](/applications/data-classification-enrichment). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_data_enrichment_header_name: 'x-human-data-enrichment', // ... } ``` --- ### HUMAN Challenge & hard block customization These configurations let you customize the [HUMAN Challenge block page](/applications/create-a-human-challenge) as well as the hard block page, which appears when a request is blocked without a Challenge. Hard block pages inherit the same styling as the HUMAN Challenge according to the following configurations and cannot be customized separately. **`px_css_ref`** `string` A way to include a custom CSS file to the block page. Maps to `{{cssRef}}` in the hard block page template. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_css_ref: 'https://www.example.com/custom_style.css', // ... } ``` --- **`px_js_ref`** `string` A way to include custom JavaScript to the block page. This script will run after the default JavaScript scripts. Maps to `{{jsRef}}` in the hard block page template. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_js_ref: 'https://www.example.com/custom_script.js', // ... } ``` --- **`px_custom_logo`** `string` — default: "" Adds a custom logo to the [HUMAN Challenge](/applications/create-a-human-challenge) block page via URL. Maps to `{{customLogo}}` in the hard block page template. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_logo: 'https://www.example.com/custom_logo.png', // ... } ``` --- **`px_custom_block_on_error_message`** `string` — default: "" A custom message to display on the HUMAN Challenge block page when an error occurs (for example, if the Challenge script fails to load). When unset, a default message is shown. Does not apply to the hard block page. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_block_on_error_message: 'Please check your connection and try again.', // ... } ``` --- ### MCP protection These configurations let the Enforcer recognize and verify Model Context Protocol (MCP) requests. When enabled, the Enforcer extracts MCP JSON-RPC metadata such as the method, tool name, tool argument keys, and session id, then sends these to the **Risk API** for assessment. You can use these configurations in combination with other [AgenticTrust-related features](/applications/getting-started-with-agentictrust) to enforce Agentic traffic. **`px_agentic_trust_enabled`** `boolean` — default: false Whether to enable AgenticTrust verification for MCP requests. * `true:` Enable MCP verification * `false:` Disable MCP verification **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_agentic_trust_enabled: true, // ... } ``` --- **`px_agentic_trust_mcp_endpoint_path`** `string` — default: /mcp The MCP endpoint path used for AgenticTrust verification. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_agentic_trust_mcp_endpoint_path: '/mcp', // ... } ``` --- ### Mobile support Enforcers with Mobile Support automatically recognize and handle requests coming from HUMAN's [Mobile SDK](/applications/mobile-sdk-intro). Since mobile apps don't add cookies as part of HTTP requests, HUMAN sends Risk Cookies as headers instead of cookies. Further, because mobile user-agents can change during the application's flow, these headers are considered tokens instead of being signed with the user-agent. **`px_token_version`** `"2" | "3"` — default: 3 The Risk Cookie version number the Mobile SDK can expect from requests from mobile applications. * `2`: Denotes the Risk Cookie V2. * `3`: Denotes the Risk Cookie V3. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_token_version: '3', // ... } ``` --- ### Monitored routes These configurations let you specify routes that should be monitored by the Enforcer, which means their requests will never be blocked, even when the Enforcer is in [`active_blocking`](#px_module_mode) mode. This means that these routes will go through the full Enforcer workflow and generate risk and async activities, but all block activities will only be simulated blocks on these routes. Primitive string values are treated as path prefixes. For example, `/login` also matches `/login/callback`. **`px_monitored_routes`** `array` — default: \[] A list of endpoints to be monitored rather than blocked by the Enforcer, even when the Enforcer is in [`active_blocking`](#px_module_mode) mode. Supports strings or regular expressions, including regex-formatted strings (for example, `"/^/regex/formatted/string/i"`). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_monitored_routes: ['/monitored_route', /.*\/monitored\/regex$/], // ... } ``` --- **`px_custom_is_monitored_request`** `function` — default: null > **Warning** > > This configuration is meant for cases that require more complex logic. We recommended you use [`px_monitored_routes`](#px_monitored_routes) for most cases. A custom function that lets you define which endpoints should be monitored based on custom logic. It accepts the incoming request as an argument and returns a boolean indicating whether the request should be monitored. **Parameters:** * `request:` [CloudFrontRequest](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) **Returns:** A boolean or a Promise resolving to a boolean. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_is_monitored_request: (request: CloudFrontRequest): boolean | Promise => { return request.method === 'GET' && request.uri.includes('/monitored'); }, // ... } ``` --- ### PXHD cookie **`px_secured_pxhd_enabled`** `boolean` — default: false > **Warning** > > If you are manually installing the Enforcer, you must [Upload the HumanActivities Lambda](/applications/aws-lambdaedge/v4/manual-installation#upload-the-humanactivities-lambda) to enable this feature. The PX Hashed Data (PXHD or `_pxhd`) cookie links the first risk request with the browser activities as detected by the **Sensor** for better user tracking. It can also add more information that's shared between the HUMAN Collector, Enforcer, and Sensor. This configuration determines whether the [`Secure` cookie attribute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies#block_access_to_your_cookies) is added when setting the PXHD cookie. See [Use of cookies & web storage](/applications/use-of-cookies-web-storage) for more information. * `true`: Adds the `Secure` attribute to the PXHD cookie * `false`: Does not add the `Secure` attribute to the PXHD cookie **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_secured_pxhd_enabled: true, // ... } ``` --- ### Remote Configuration Remote Configuration lets you update your Enforcer's configuration from the HUMAN portal rather than interacting with the Enforcer package directly. **`px_logger_auth_token`** `string` — default: "" An alternative to the [basic logger](#px_logger_severity) configuration. This sends Enforcer logs to HUMAN's logging service if a specific header is present on the request. This is particularly useful for expedited debugging, diagnosis, and resolution of any integration or Enforcer-related issues. [Contact HUMAN](/applications/human-customer-support) to receive your token. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_logger_auth_token: '', // ... } ``` --- **`px_remote_config_auth_token`** `string` — default: "" The token used to authenticate the Enforcer with the HUMAN Remote Configuration service. [Contact HUMAN](/applications/human-customer-support) to receive your token. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_remote_config_auth_token: '', // ... } ``` --- **`px_remote_config_id`** `string` — default: "" The ID associated with the Remote Configuration. [Contact HUMAN](/applications/human-customer-support) to receive your ID. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_remote_config_id: '00000000-0000-0000-0000-000000000000', // ... } ``` --- ### Response custom parameters These configurations enrich async activities with values derived from the origin response. **`px_enrich_response_custom_parameters`** `function` — default: null A function that receives the configuration and the response from the origin and returns up to ten fields: `custom_param11` through `custom_param20`. These are merged into `page_requested`, `additional_s2s`, and simulated block activities. There is a limit of ten response custom parameters. **Parameters:** * `config: HumanSecurityConfiguration` * `response:` [CloudFrontResponse](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-response) **Returns:** An object with `custom_param11`–`custom_param20` keys, or a Promise resolving to that object. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_enrich_response_custom_parameters: async ( config: HumanSecurityConfiguration, response: CloudFrontResponse, ): ResponseCustomParameters | Promise => { return { custom_param11: 'hardcoded value', custom_param12: response.headers['x-request-id']?.[0]?.value ?? '', custom_param13: response.status, // ... up to custom_param20 }; }, // ... } ``` --- ### Sensitive headers removal **`px_sensitive_headers`** `string[]` — default: \["cookie", "cookies"] Specifies certain headers that should not be forwarded to any other destination, including the HUMAN **Detector**. While HUMAN's detection system will continue to use these headers to determine whether to block or not, the specified headers won't be forwarded from the Enforcer, won't appear in Enforcer activities, and won't be sent to any other IP if the Enforcer acts as a proxy. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_sensitive_headers: ['x-sensitive-token'], // ... } ``` --- ### Sensitive routes These configurations let you specify certain routes that need particularly stringent protection from attacks, such as endpoints that execute payments or handle personal information. Sensitive routes will always trigger a **Risk API** call even if the request contains a valid, unexpired, low-score cookie. Primitive string values are treated as path prefixes. For example, `/login` also matches `/login/callback`. > **Note** > > Requests with high-score cookies won't send a Risk API call. **`px_sensitive_routes`** `array` — default: \[] A list of prefixes for all routes that should be considered sensitive. Supports strings or regular expressions, including regex-formatted strings (for example, `"/^/regex/formatted/string/i"`). **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_sensitive_routes: ['/login', /.*\/sensitive\/regex$/], // ... } ``` --- **`px_custom_is_sensitive_request`** `function` — default: null > **Warning** > > This configuration is meant for cases that require more complex logic. We recommended you use [`px_sensitive_routes`](#px_sensitive_routes) for most cases. A custom function that lets you define which requests should be considered sensitive based on custom logic. It accepts the incoming request as an argument and returns a boolean indicating whether the request should be considered sensitive. **Parameters:** * `request:` [CloudFrontRequest](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html#lambda-event-structure-request) **Returns:** A boolean or a Promise resolving to a boolean. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_custom_is_sensitive_request: (request: CloudFrontRequest): boolean | Promise => { return request.method === 'POST' || request.method === 'PUT'; }, // ... } ``` --- ### URL-decode reserved characters **`px_url_decode_reserved_characters`** `boolean` — default: false When `true`, the Enforcer will decode [reserved characters](https://datatracker.ietf.org/doc/html/rfc3986#section-2.2) such as `%3F` and `%2F` in the request URL path prior to processing. In other words, the Enforcer will treat the URIs `/login%3F.ico` and `/login?.ico` as equivalent. By default, the Enforcer doesn't decode reserved characters and treats these URLs separately. * `true`: Decode reserved characters in the request URL. * `false`: Do not decode reserved characters in the request URL. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_url_decode_reserved_characters: true, // ... } ``` --- ### Users identifiers These configurations let you extract user identifiers from a JWT carried on the request either in a cookie or a header. They're closely related to the [Accounts](/applications/about-the-accounts-overview-dashboard) and [Account Takeover or Fake Account](/applications/about-the-recent-attacks-dashboard) features in Sightline Cyberfraud Defense. The Enforcer reads the JWT from the configured cookie first, then from the configured header if cookie extraction does not succeed. Field names support dot notation for nested JWT claim (for example, `product.id`). **`px_jwt_cookie_name`** `string` — default: "" The name of the cookie that contains the JWT token that HUMAN should extract user identifiers from. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_jwt_cookie_name: 'auth', // ... } ``` --- **`px_jwt_cookie_user_id_field_name`** `string` — default: "" The field name in the JWT object, extracted from the JWT cookie, that contains the user ID to be extracted and reported. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_jwt_cookie_user_id_field_name: 'nameID', // ... } ``` --- **`px_jwt_cookie_additional_field_names`** `string[]` — default: \[] The field names in the JWT object, extracted from the JWT cookie, that should be extracted and reported in addition to the user ID. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_jwt_cookie_additional_field_names: ['exp', 'iss'], // ... } ``` --- **`px_jwt_header_name`** `string` — default: "" The name of the header that contains the JWT token that HUMAN should extract user identifiers from. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_jwt_header_name: 'x-jwt-authorization', // ... } ``` --- **`px_jwt_header_user_id_field_name`** `string` — default: "" The field name in the JWT object, extracted from the JWT header, that contains the user ID to be extracted and reported. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_jwt_header_user_id_field_name: 'sub', // ... } ``` --- **`px_jwt_header_additional_field_names`** `string[]` — default: \[] The field names in the JWT object, extracted from the JWT header, that should be extracted and reported in addition to the user ID. **`Example`** ```ts Example const config: HumanSecurityConfiguration = { // ... px_jwt_header_additional_field_names: ['exp', 'iss'], // ... } ``` ---