> 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.

# Fastly Rust Compute@Edge 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. `PXConfig` Config Store

> **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.

You can also store sensitive values in a **Fastly Secret Store**. When `PXEnforcer` is initialized with a non-empty Secret Store name (default: `PXSecrets`), the Enforcer overlays [sensitive configurations](#sensitive-configurations) from the Secret Store. These values override Config Store ones. Missing secrets are non-fatal and leave the Config Store value (or default) in place. Pass an empty string for the Secret Store name to disable secret loading.

A small number of options are runtime-only callbacks that cannot be expressed as Config Store values. These are set directly on the Enforcer in your Rust code before calling `px.enforce()` and are documented in [Runtime callbacks](#runtime-callbacks).

## Types & format

The Config Store stores every value as a string. The Enforcer parses each value according to the type of the configuration:

* **String**: A sequence of characters without quotation marks, e.g. `my_string`
* **Boolean**: A `true` or `false` value, e.g. `true`
* **Number**: A numeric value, e.g. `100`
* **List**: A comma-separated list of values without quotation marks, e.g. `value1, value2`
* **Regex list**: A comma-separated list of regular expressions without quotation marks, e.g. `^/graphql$, ^/api/graphql$`
* **Object**: A JSON-encoded value. Used by [`px_login_credentials_extraction`](#px_login_credentials_extraction).

You should add each configuration to the Fastly Config Store as a key-value pair. Enter both the key name and the value without quotation marks (`''`, `""`). For array or list values, separate items with commas.

## Deployment

For non-sensitive configurations, we recommend using a Fastly [Config Store](https://www.fastly.com/documentation/guides/compute/edge-data-storage/working-with-config-stores/). However, for more sensitive configurations, we strongly recommend using a Fastly [Secret Store](https://www.fastly.com/documentation/guides/compute/edge-data-storage/working-with-secret-stores/) instead. Populated values stored in a Secret Store override the same values in the Config Store.

#### Non-sensitive configurations

Non-sensitive configurations are generally considered any configuration not listed in [sensitive configurations](#sensitive-configurations). To deploy these configurations:

1. Log in to your Fastly account.
2. Navigate to **Resources > Config Stores.**
3. Add or update a configuration as a key-value pair in the `PXConfig` Config Store.
4. Click **Save.**

#### Sensitive configurations

We recommend adding the following configurations to a Secret Store:

| Configuration name                              | Type                       | Notes                                                |
| ----------------------------------------------- | -------------------------- | ---------------------------------------------------- |
| [`px_app_id`](#px_app_id)                       | String                     | HUMAN application ID                                 |
| [`px_cookie_secret`](#px_cookie_secret)         | String or Array of strings | Secret used to validate risk cookies                 |
| [`px_auth_token`](#px_auth_token)               | String                     | Bearer token for Risk API, activities, and telemetry |
| [`px_logger_auth_token`](#px_logger_auth_token) | String                     | Token for header-based Enforcer log collection       |

To deploy these configurations:

1. Log in to your Fastly account.
2. Navigate to **Resources > Secret Stores.**
3. Add or update a configuration as a key-value pair in the `PXSecrets` Secret Store (or the name you passed to `PXEnforcer::new`).
4. Click **Save.**

Alternatively, you can also use `pxconfig.sh` to populate the Store with required values automatically.

```sh showLineNumbers={false}
Required options:
-s, --service-id=SERVICE_ID       specify a service to deploy the Config store
-v, --version=VER                 specify a service version
-a, --appid=APPID                 specify an appid
-c, --cookie_secret=SECRET        specify a cookie_secret
-t, --auth_token=TOKEN            specify an auth_token
```

## Quick reference

#### Required

| Feature name                           | Key                                     | Type                       | Default | Description                                                                                                                               |
| :------------------------------------- | :-------------------------------------- | :------------------------- | :------ | :---------------------------------------------------------------------------------------------------------------------------------------- |
| [Application ID](#px_app_id)           | [`px_app_id`](#px_app_id)               | String                     | `""`    | The HUMAN application ID. Required to initialize the Enforcer. May be set in Config Store or Secret Store.                                |
| [Authentication token](#px_auth_token) | [`px_auth_token`](#px_auth_token)       | String                     | `""`    | The token used for authorization with the HUMAN backend. Required to initialize the Enforcer. May be set in Config Store or Secret Store. |
| [Cookie secret](#px_cookie_secret)     | [`px_cookie_secret`](#px_cookie_secret) | String or Array of strings | `""`    | The secret used to validate the risk cookie. Required to initialize the Enforcer. May be set in Config Store or Secret Store.             |

#### Basic

<table searchable>
  <colgroup>
    <col />

    <col />

    <col />

    <col />

    <col />
  </colgroup>

  <thead>
    <tr>
      <th>
        Feature name
      </th>

      <th>
        Key
      </th>

      <th>
        Type
      </th>

      <th>
        Default
      </th>

      <th>
        Description
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        [S2S timeout](#px_s2s_timeout)
      </td>

      <td>
        [<code>px\_<wbr />s2s\_<wbr />timeout</code>](#px_s2s_timeout)
      </td>

      <td>
        Integer
      </td>

      <td>
        `2000`
      </td>

      <td>
        The timeout for the S2S request.
      </td>
    </tr>

    <tr>
      <td>
        [Blocking score](#px_blocking_score)
      </td>

      <td>
        [<code>px\_<wbr />blocking\_<wbr />score</code>](#px_blocking_score)
      </td>

      <td>
        Integer
      </td>

      <td>
        `100`
      </td>

      <td>
        The blocking score.
      </td>
    </tr>

    <tr>
      <td>
        [Max user agent length](#px_user_agent_max_length)
      </td>

      <td>
        [<code>px\_<wbr />user\_<wbr />agent\_<wbr />max\_<wbr />length</code>](#px_user_agent_max_length)
      </td>

      <td>
        Integer
      </td>

      <td>
        `8528`
      </td>

      <td>
        The maximum length of the user agent.
      </td>
    </tr>

    <tr>
      <td>
        [Max risk cookie length](#px_risk_cookie_max_length)
      </td>

      <td>
        [<code>px\_<wbr />risk\_<wbr />cookie\_<wbr />max\_<wbr />length</code>](#px_risk_cookie_max_length)
      </td>

      <td>
        Integer
      </td>

      <td>
        `2048`
      </td>

      <td>
        The maximum length of the risk cookie.
      </td>
    </tr>

    <tr>
      <td>
        [Min risk cookie iterations](#px_risk_cookie_min_iterations)
      </td>

      <td>
        [<code>px\_<wbr />risk\_<wbr />cookie\_<wbr />min\_<wbr />iterations</code>](#px_risk_cookie_min_iterations)
      </td>

      <td>
        Integer
      </td>

      <td>
        `500`
      </td>

      <td>
        The minimum number of iterations for the risk cookie.
      </td>
    </tr>

    <tr>
      <td>
        [Max risk cookie iterations](#px_risk_cookie_max_iterations)
      </td>

      <td>
        [<code>px\_<wbr />risk\_<wbr />cookie\_<wbr />max\_<wbr />iterations</code>](#px_risk_cookie_max_iterations)
      </td>

      <td>
        Integer
      </td>

      <td>
        `5000`
      </td>

      <td>
        The maximum number of iterations for the risk cookie.
      </td>
    </tr>

    <tr>
      <td>
        [Debug](#px_debug)
      </td>

      <td>
        [<code>px\_<wbr />debug</code>](#px_debug)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        Whether to enable verbose PerimeterX debug logs.
      </td>
    </tr>

    <tr>
      <td>
        [IP headers](#px_ip_headers)
      </td>

      <td>
        [<code>px\_<wbr />ip\_<wbr />headers</code>](#px_ip_headers)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        `[]`
      </td>

      <td>
        The IP headers to use for the Enforcer.
      </td>
    </tr>

    <tr>
      <td>
        [Module enabled](#px_module_enabled)
      </td>

      <td>
        [<code>px\_<wbr />module\_<wbr />enabled</code>](#px_module_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        Whether to enable the entire module.
      </td>
    </tr>

    <tr>
      <td>
        [Module mode](#px_module_mode)
      </td>

      <td>
        [<code>px\_<wbr />module\_<wbr />mode</code>](#px_module_mode)
      </td>

      <td>
        `"monitor"`

        , 

        `"active_blocking"`
      </td>

      <td>
        `"monitor"`
      </td>

      <td>
        Whether the Enforcer returns block responses or only monitors.
      </td>
    </tr>
  </tbody>
</table>

#### Optional

<table searchable>
  <colgroup>
    <col />

    <col />

    <col />

    <col />

    <col />
  </colgroup>

  <thead>
    <tr>
      <th>
        Feature name
      </th>

      <th>
        Key
      </th>

      <th>
        Type
      </th>

      <th>
        Default
      </th>

      <th>
        Description
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        [Advanced blocking response (ABR)](#advanced-blocking-response-abr)
      </td>

      <td>
        [<code>px\_<wbr />advanced\_<wbr />blocking\_<wbr />response\_<wbr />enabled</code>](#px_advanced_blocking_response_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `true`
      </td>

      <td>
        Whether the ABR feature is enabled.
      </td>
    </tr>

    <tr>
      <td>
        [Bypass monitor header](#bypass-monitor-header)
      </td>

      <td>
        [<code>px\_<wbr />bypass\_<wbr />monitor\_<wbr />header</code>](#px_bypass_monitor_header)
      </td>

      <td>
        String
      </td>

      <td>
        `"x-px-block"`
      </td>

      <td>
        The header name to trigger Enforcer blocking workflow even in 

        [monitor mode](#px_module_mode)

        .
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />login\_<wbr />credentials\_<wbr />extraction\_<wbr />enabled</code>](#px_login_credentials_extraction_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        Whether to enable Credential Intelligence.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />login\_<wbr />credentials\_<wbr />extraction</code>](#px_login_credentials_extraction)
      </td>

      <td>
        Object
      </td>

      <td>
        `[]`
      </td>

      <td>
        An array of configuration objects for each credential endpoint. See 

        [details](#px_login_credentials_extraction)

         for more information.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />credentials\_<wbr />intelligence\_<wbr />version</code>](#px_credentials_intelligence_version)
      </td>

      <td>
        `"v2"`

        , 

        `"multistep_sso"`

        , 

        `"both"`
      </td>

      <td>
        `"both"`
      </td>

      <td>
        The default credential hashing protocol applied to endpoints that do not specify a 

        `protocol`

         field.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />compromised\_<wbr />credentials\_<wbr />header</code>](#px_compromised_credentials_header)
      </td>

      <td>
        String
      </td>

      <td>
        `"px-compromised-credentials"`
      </td>

      <td>
        The header name to set on the incoming request when credentials are compromised.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />additional\_<wbr />s2s\_<wbr />activity\_<wbr />enabled</code>](#px_additional_s2s_activity_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `true`
      </td>

      <td>
        Whether to send the 

        `additional_s2s`

         activity automatically along with the 

        `page_requested`

         activity.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />additional\_<wbr />s2s\_<wbr />activity\_<wbr />header\_<wbr />enabled</code>](#px_additional_s2s_activity_header_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        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_additional_s2s_activity_enabled)

         activity isn't sent automatically.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />send\_<wbr />raw\_<wbr />username\_<wbr />on\_<wbr />additional\_<wbr />s2s\_<wbr />activity</code>](#px_send_raw_username_on_additional_s2s_activity)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        Whether to send the raw username on the 

        `additional_s2s`

         activity.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />login\_<wbr />successful\_<wbr />reporting\_<wbr />method</code>](#px_login_successful_reporting_method)
      </td>

      <td>
        `"status"`

        , 

        `"body"`

        , 

        `"header"`

        , 

        `"custom"`
      </td>

      <td>
        `"status"`
      </td>

      <td>
        The default login-success detection method applied to endpoints that don't override it.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />login\_<wbr />successful\_<wbr />status</code>](#px_login_successful_status)
      </td>

      <td>
        Array of integers
      </td>

      <td>
        `200`
      </td>

      <td>
        The default HTTP status codes that indicate a successful login.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />login\_<wbr />successful\_<wbr />body\_<wbr />regex</code>](#px_login_successful_body_regex)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        The default regular expression used to detect a successful login from the response body.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />login\_<wbr />successful\_<wbr />header\_<wbr />name</code>](#px_login_successful_header_name)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        The default response header name used to detect a successful login.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>px\_<wbr />login\_<wbr />successful\_<wbr />header\_<wbr />value</code>](#px_login_successful_header_value)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        The default response header value used to detect a successful login.
      </td>
    </tr>

    <tr>
      <td>
        [CORS support](#cors-support)
      </td>

      <td>
        [<code>px\_<wbr />cors\_<wbr />support\_<wbr />enabled</code>](#px_cors_support_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        Whether to enable CORS support.
      </td>
    </tr>

    <tr>
      <td>
        [CORS support](#cors-support)
      </td>

      <td>
        [<code>px\_<wbr />cors\_<wbr />preflight\_<wbr />request\_<wbr />filter\_<wbr />enabled</code>](#px_cors_preflight_request_filter_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        Whether to filter preflight requests that pass the 

        [`px_cors_custom_preflight_handler`](#px_cors_custom_preflight_handler)

         from the Enforcer.
      </td>
    </tr>

    <tr>
      <td>
        [Custom cookie header](#custom-cookie-header)
      </td>

      <td>
        [<code>px\_<wbr />custom\_<wbr />cookie\_<wbr />header</code>](#px_custom_cookie_header)
      </td>

      <td>
        String
      </td>

      <td>
        `"x-px-cookies"`
      </td>

      <td>
        A custom name for the header that contains HUMAN's cookies
      </td>
    </tr>

    <tr>
      <td>
        [Enforced routes](#enforced-routes)
      </td>

      <td>
        [<code>px\_<wbr />enforced\_<wbr />routes</code>](#px_enforced_routes)
      </td>

      <td>
        Array of strings or 

        `RegExp`
      </td>

      <td>
        `[]`
      </td>

      <td>
        An array of regex routes or prefixes that should be enforced even in 

        [monitor mode](#px_module_mode)

        .
      </td>
    </tr>

    <tr>
      <td>
        [Extracted cookies](#extracted-cookies)
      </td>

      <td>
        [<code>px\_<wbr />extracted\_<wbr />cookies</code>](#px_extracted_cookies)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        `[]`
      </td>

      <td>
        Cookie names whose values are copied into the 

        Risk API

         additional fields.
      </td>
    </tr>

    <tr>
      <td>
        [Filters](#filters)
      </td>

      <td>
        [<code>px\_<wbr />filter\_<wbr />by\_<wbr />extension</code>](#px_filter_by_extension)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        All common file extensions. See 

        [details](#px_filter_by_extension)

         for more information.
      </td>

      <td>
        An array of file extensions that should be ignored by the Enforcer.
      </td>
    </tr>

    <tr>
      <td>
        [Filters](#filters)
      </td>

      <td>
        [<code>px\_<wbr />filter\_<wbr />by\_<wbr />http\_<wbr />method</code>](#px_filter_by_http_method)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        `[]`
      </td>

      <td>
        An array of HTTP methods that should be ignored by the Enforcer.
      </td>
    </tr>

    <tr>
      <td>
        [Filters](#filters)
      </td>

      <td>
        [<code>px\_<wbr />filter\_<wbr />by\_<wbr />ip</code>](#px_filter_by_ip)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        `[]`
      </td>

      <td>
        An array of IP addresses or CIDR ranges that should be ignored by the Enforcer.
      </td>
    </tr>

    <tr>
      <td>
        [Filters](#filters)
      </td>

      <td>
        [<code>px\_<wbr />filter\_<wbr />by\_<wbr />route</code>](#px_filter_by_route)
      </td>

      <td>
        Array of strings or 

        `RegExp`
      </td>

      <td>
        `[]`
      </td>

      <td>
        An array of routes or prefixes that should be ignored by the Enforcer.
      </td>
    </tr>

    <tr>
      <td>
        [Filters](#filters)
      </td>

      <td>
        [<code>px\_<wbr />filter\_<wbr />by\_<wbr />user\_<wbr />agent</code>](#px_filter_by_user_agent)
      </td>

      <td>
        Array of strings or 

        `RegExp`
      </td>

      <td>
        `[]`
      </td>

      <td>
        An array of user agents that should be ignored by the Enforcer.
      </td>
    </tr>

    <tr>
      <td>
        [First party](#first-party)
      </td>

      <td>
        [<code>px\_<wbr />first\_<wbr />party\_<wbr />enabled</code>](#px_first_party_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `true`
      </td>

      <td>
        Whether to enable first party mode for Bot Defender or Sightline Cyberfraud Defense.
      </td>
    </tr>

    <tr>
      <td>
        [GraphQL support](#graphql-support)
      </td>

      <td>
        [<code>px\_<wbr />graphql\_<wbr />enabled</code>](#px_graphql_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        Whether to extract GraphQL operation data from requests that match 

        [GraphQL routes](#px_graphql_routes)

        .
      </td>
    </tr>

    <tr>
      <td>
        [GraphQL support](#graphql-support)
      </td>

      <td>
        [<code>px\_<wbr />graphql\_<wbr />routes</code>](#px_graphql_routes)
      </td>

      <td>
        Array of strings or 

        `RegExp`
      </td>

      <td>
        `["/graphql"]`
      </td>

      <td>
        Path prefixes or patterns to enable GraphQL support on.
      </td>
    </tr>

    <tr>
      <td>
        [GraphQL support](#graphql-support)
      </td>

      <td>
        [<code>px\_<wbr />sensitive\_<wbr />graphql\_<wbr />operation\_<wbr />names</code>](#px_sensitive_graphql_operation_names)
      </td>

      <td>
        Array of strings or 

        `RegExp`
      </td>

      <td>
        `[]`
      </td>

      <td>
        Operation names and keywords to trigger the 

        Risk API

         for regardless of cookies.
      </td>
    </tr>

    <tr>
      <td>
        [GraphQL support](#graphql-support)
      </td>

      <td>
        [<code>px\_<wbr />sensitive\_<wbr />graphql\_<wbr />operation\_<wbr />types</code>](#px_sensitive_graphql_operation_types)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        `[]`
      </td>

      <td>
        Operation types to trigger the 

        Risk API

         for regardless of cookies.
      </td>
    </tr>

    <tr>
      <td>
        [GraphQL support](#graphql-support)
      </td>

      <td>
        [<code>px\_<wbr />graphql\_<wbr />keywords</code>](#px_graphql_keywords)
      </td>

      <td>
        Array of strings or 

        `RegExp`
      </td>

      <td>
        `[]`
      </td>

      <td>
        An array of strings or regular expressions.
      </td>
    </tr>

    <tr>
      <td>
        [GraphQL support](#graphql-support)
      </td>

      <td>
        [<code>px\_<wbr />graphql\_<wbr />body\_<wbr />max\_<wbr />length</code>](#px_graphql_body_max_length)
      </td>

      <td>
        Integer
      </td>

      <td>
        `1048576`
      </td>

      <td>
        The maximum body prefix length in bytes that are read while parsing the GraphQL JSON body.
      </td>
    </tr>

    <tr>
      <td>
        [Header data enrichment](#header-data-enrichment)
      </td>

      <td>
        [<code>px\_<wbr />data\_<wbr />enrichment\_<wbr />header\_<wbr />name</code>](#px_data_enrichment_header_name)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        The header name to use for sending 

        [data classification enrichment](/applications/data-classification-enrichment)

         values to the request.
      </td>
    </tr>

    <tr>
      <td>
        [HUMAN Challenge & hard block customization](#human-challenge--hard-block-customization)
      </td>

      <td>
        [<code>px\_<wbr />css\_<wbr />ref</code>](#px_css_ref)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        A URL to a custom CSS file to customize the 

        [HUMAN Challenge](/applications/customize-challenge-look-feel)

         and hard block page.
      </td>
    </tr>

    <tr>
      <td>
        [HUMAN Challenge & hard block customization](#human-challenge--hard-block-customization)
      </td>

      <td>
        [<code>px\_<wbr />js\_<wbr />ref</code>](#px_js_ref)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        A URL to a custom JavaScript file to load with the block page.
      </td>
    </tr>

    <tr>
      <td>
        [HUMAN Challenge & hard block customization](#human-challenge--hard-block-customization)
      </td>

      <td>
        [<code>px\_<wbr />custom\_<wbr />logo</code>](#px_custom_logo)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        The URL of a custom logo to display on the block page
      </td>
    </tr>

    <tr>
      <td>
        [Logging](#logging)
      </td>

      <td>
        [<code>px\_<wbr />log\_<wbr />endpoint</code>](#px_log_endpoint)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        The name of the Fastly logging endpoint used by platform-specific activity delivery.
      </td>
    </tr>

    <tr>
      <td>
        [Logging](#logging)
      </td>

      <td>
        [<code>px\_<wbr />logger\_<wbr />auth\_<wbr />token</code>](#px_logger_auth_token)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        Authentication token for HUMAN's logger service for specific headers.
      </td>
    </tr>

    <tr>
      <td>
        [MCP protection](#mcp-protection)
      </td>

      <td>
        [<code>px\_<wbr />agentic\_<wbr />trust\_<wbr />enabled</code>](#px_agentic_trust_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        Whether to enable AgenticTrust verification for MCP requests.
      </td>
    </tr>

    <tr>
      <td>
        [MCP protection](#mcp-protection)
      </td>

      <td>
        [<code>px\_<wbr />agentic\_<wbr />trust\_<wbr />mcp\_<wbr />endpoint\_<wbr />path</code>](#px_agentic_trust_mcp_endpoint_path)
      </td>

      <td>
        String
      </td>

      <td>
        `"/mcp"`
      </td>

      <td>
        The MCP endpoint path used for AgenticTrust verification.
      </td>
    </tr>

    <tr>
      <td>
        [Mobile support](#mobile-support)
      </td>

      <td>
        [<code>px\_<wbr />token\_<wbr />version</code>](#px_token_version)
      </td>

      <td>
        `"2"`

        , 

        `"3"`
      </td>

      <td>
        `"3"`
      </td>

      <td>
        The Risk Cookie version number the Mobile SDK can expect from requests from mobile applications.
      </td>
    </tr>

    <tr>
      <td>
        [Monitored routes](#monitored-routes)
      </td>

      <td>
        [<code>px\_<wbr />monitored\_<wbr />routes</code>](#px_monitored_routes)
      </td>

      <td>
        Array of strings or 

        `RegExp`
      </td>

      <td>
        `[]`
      </td>

      <td>
        Routes that behave as if the Enforcer is in 

        [monitor mode](#px_module_mode)

         even when actively blocking.
      </td>
    </tr>

    <tr>
      <td>
        [PXHD cookie](#pxhd-cookie)
      </td>

      <td>
        [<code>px\_<wbr />secured\_<wbr />pxhd\_<wbr />enabled</code>](#px_secured_pxhd_enabled)
      </td>

      <td>
        Boolean
      </td>

      <td>
        `false`
      </td>

      <td>
        Whether the 

        [`_pxhd` cookie](/applications/use-of-cookies-web-storage)

         should include the 

        `Secure`

         attribute.
      </td>
    </tr>

    <tr>
      <td>
        [PXHD cookie](#pxhd-cookie)
      </td>

      <td>
        [<code>px\_<wbr />pxhd\_<wbr />domain</code>](#px_pxhd_domain)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        The domain of the 

        [`_pxhd` cookie](/applications/use-of-cookies-web-storage)

        .
      </td>
    </tr>

    <tr>
      <td>
        [Sensitive headers removal](#sensitive-headers-removal)
      </td>

      <td>
        [<code>px\_<wbr />sensitive\_<wbr />headers</code>](#px_sensitive_headers)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        `["cookie", "cookies"]`
      </td>

      <td>
        Requests with the specified headers will be considered sensitive and removed from requests sent by the Enforcer.
      </td>
    </tr>

    <tr>
      <td>
        [Sensitive routes](#sensitive-routes)
      </td>

      <td>
        [<code>px\_<wbr />sensitive\_<wbr />routes</code>](#px_sensitive_routes)
      </td>

      <td>
        Array of strings or 

        `RegExp`
      </td>

      <td>
        `[]`
      </td>

      <td>
        Routes that the Enforcer will always trigger a 

        Risk API

         call for.
      </td>
    </tr>

    <tr>
      <td>
        [Sensitive routes](#sensitive-routes)
      </td>

      <td>
        [<code>px\_<wbr />sensitive\_<wbr />routes\_<wbr />regex</code>](#px_sensitive_routes_regex)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        `[]`
      </td>

      <td>
        A list of regular expressions for all routes that should be considered sensitive.
      </td>
    </tr>

    <tr>
      <td>
        [Users identifiers](#users-identifiers)
      </td>

      <td>
        [<code>px\_<wbr />jwt\_<wbr />cookie\_<wbr />name</code>](#px_jwt_cookie_name)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        Name of the cookie that contains the JWT token.
      </td>
    </tr>

    <tr>
      <td>
        [Users identifiers](#users-identifiers)
      </td>

      <td>
        [<code>px\_<wbr />jwt\_<wbr />cookie\_<wbr />user\_<wbr />id\_<wbr />field\_<wbr />name</code>](#px_jwt_cookie_user_id_field_name)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        Name of the field's path that contains the user ID.
      </td>
    </tr>

    <tr>
      <td>
        [Users identifiers](#users-identifiers)
      </td>

      <td>
        [<code>px\_<wbr />jwt\_<wbr />cookie\_<wbr />additional\_<wbr />field\_<wbr />names</code>](#px_jwt_cookie_additional_field_names)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        `[]`
      </td>

      <td>
        Additional field paths to extract from the JWT cookie.
      </td>
    </tr>

    <tr>
      <td>
        [Users identifiers](#users-identifiers)
      </td>

      <td>
        [<code>px\_<wbr />jwt\_<wbr />header\_<wbr />name</code>](#px_jwt_header_name)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        Name of the header that contains the JWT token.
      </td>
    </tr>

    <tr>
      <td>
        [Users identifiers](#users-identifiers)
      </td>

      <td>
        [<code>px\_<wbr />jwt\_<wbr />header\_<wbr />user\_<wbr />id\_<wbr />field\_<wbr />name</code>](#px_jwt_header_user_id_field_name)
      </td>

      <td>
        String
      </td>

      <td>
        `""`
      </td>

      <td>
        Name of the field path that contains the user ID. Extracted from the header.
      </td>
    </tr>

    <tr>
      <td>
        [Users identifiers](#users-identifiers)
      </td>

      <td>
        [<code>px\_<wbr />jwt\_<wbr />header\_<wbr />additional\_<wbr />field\_<wbr />names</code>](#px_jwt_header_additional_field_names)
      </td>

      <td>
        Array of strings
      </td>

      <td>
        `[]`
      </td>

      <td>
        Additional JWT fields to extract from the header.
      </td>
    </tr>
  </tbody>
</table>

#### Runtime callbacks

<table searchable>
  <colgroup>
    <col />

    <col />

    <col />

    <col />

    <col />
  </colgroup>

  <thead>
    <tr>
      <th>
        Feature name
      </th>

      <th>
        Key
      </th>

      <th>
        Type
      </th>

      <th>
        Default
      </th>

      <th>
        Description
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        [Additional activity handler](#additional-activity-handler)
      </td>

      <td>
        [<code>px\_<wbr />additional\_<wbr />activity\_<wbr />handler</code>](#px_additional_activity_handler)
      </td>

      <td>
        Function
      </td>

      <td>
        Empty
      </td>

      <td>
        The function to invoke after the async activity. (

        `page_requested`

         or 

        `block`

        ) is sent to the HUMAN backend after enforcement.
      </td>
    </tr>

    <tr>
      <td>
        [CORS support](#cors-support)
      </td>

      <td>
        [<code>px\_<wbr />cors\_<wbr />create\_<wbr />custom\_<wbr />block\_<wbr />response\_<wbr />headers</code>](#px_cors_create_custom_block_response_headers)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        Function to receive the original request and return an object with the custom headers to add to the block response.
      </td>
    </tr>

    <tr>
      <td>
        [CORS support](#cors-support)
      </td>

      <td>
        [<code>px\_<wbr />cors\_<wbr />custom\_<wbr />preflight\_<wbr />handler</code>](#px_cors_custom_preflight_handler)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        Preflight requests handler that returns the response before reaching the Enforcer.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>extract\_<wbr />credentials\_<wbr />callback</code>](#extract_credentials_callback)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        A custom function that accepts the request and returns the raw credentials from the request, or 

        `None`

         if neither field can be extracted.
      </td>
    </tr>

    <tr>
      <td>
        [Credentials Intelligence](#credentials-intelligence)
      </td>

      <td>
        [<code>login\_<wbr />successful\_<wbr />custom\_<wbr />callback</code>](#login_successful_custom_callback)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        A custom function that accepts the response and returns a boolean that indicates whether the login attempt was successful.
      </td>
    </tr>

    <tr>
      <td>
        [Custom parameters](#custom-parameters)
      </td>

      <td>
        [<code>px\_<wbr />enrich\_<wbr />custom\_<wbr />parameters</code>](#px_enrich_custom_parameters)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        A custom function that accepts the request and returns a map of custom parameters to add to HUMAN activities.
      </td>
    </tr>

    <tr>
      <td>
        [Enforced request callback](#enforced-request-callback)
      </td>

      <td>
        [<code>px\_<wbr />custom\_<wbr />is\_<wbr />enforced\_<wbr />request</code>](#px_custom_is_enforced_request)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        Custom function that returns whether the request should be enforced.
      </td>
    </tr>

    <tr>
      <td>
        [Filters](#filters)
      </td>

      <td>
        [<code>px\_<wbr />filter\_<wbr />by\_<wbr />custom\_<wbr />function</code>](#px_filter_by_custom_function)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        Custom function that returns whether the request should be filtered.
      </td>
    </tr>

    <tr>
      <td>
        [Hard block customization](#hard-block-customization)
      </td>

      <td>
        [<code>px\_<wbr />hardblock\_<wbr />custom\_<wbr />fn</code>](#px_hardblock_custom_fn)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        Custom function that customizes the hard-block response.
      </td>
    </tr>

    <tr>
      <td>
        [Monitored request callback](#monitored-request-callback)
      </td>

      <td>
        [<code>px\_<wbr />custom\_<wbr />is\_<wbr />monitored\_<wbr />request</code>](#px_custom_is_monitored_request)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        Custom function that returns whether the request should be monitored.
      </td>
    </tr>

    <tr>
      <td>
        [Sensitive routes](#sensitive-routes)
      </td>

      <td>
        [<code>px\_<wbr />custom\_<wbr />is\_<wbr />sensitive\_<wbr />request</code>](#px_custom_is_sensitive_request)
      </td>

      <td>
        Function
      </td>

      <td>
        null
      </td>

      <td>
        Custom function that returns whether the request should be treated as a sensitive route.
      </td>
    </tr>
  </tbody>
</table>

## Required configurations

These configurations are necessary for the Enforcer's basic functionality and features.

**`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.

> **Note**
>
> We recommend storing this value in a [Fastly Secret Store](#sensitive-configurations). If you do, it will override the `px_app_id` value in the Config Store.

**`Example`**

```sh showLineNumbers={false} Example
key: px_app_id
value: PX12345678
```

---

**`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.**

> **Note**
>
> We recommend storing this value in a [Fastly Secret Store](#sensitive-configurations). If you do, it will override the `px_auth_token` value in the Config Store.

**`Example`**

```sh showLineNumbers={false} Example
key: px_auth_token
value: <AUTH_TOKEN>
```

---

**`px_cookie_secret`** `string | string[]` — required, default: string

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.**

> **Note**
>
> We recommend storing this value in a [Fastly Secret Store](#sensitive-configurations). If you do, it will override the `px_cookie_secret` value in the Config Store.

**`Basic example`**

```sh showLineNumbers={false} Basic example
key: px_cookie_secret
value: <COOKIE_SECRET>
```

---

## Basic feature configurations

The configurations aren't strictly required, but are integral for the Enforcer's basic blocking functionality and are typically set to their default values if not manually configured.

**`px_s2s_timeout`** `integer` — default: 2000

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`**

```sh showLineNumbers={false} Example
key: px_s2s_timeout
value: 1000
```

---

**`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`**

```sh showLineNumbers={false} Example
key: px_blocking_score
value: 80
```

---

**`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`**

```sh showLineNumbers={false} Example
key: px_user_agent_max_length
value: 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`**

```sh showLineNumbers={false} Example
key: px_risk_cookie_max_length
value: 4096
```

---

**`px_risk_cookie_min_iterations`** `integer` — default: 500

The minimum accepted number of iterations for the Risk Cookie V3.

**`Example`**

```sh showLineNumbers={false} Example
key: px_risk_cookie_min_iterations
value: 500
```

---

**`px_risk_cookie_max_iterations`** `integer` — default: 5000

The maximum accepted number of iterations for the Risk Cookie V3.

**`Example`**

```sh showLineNumbers={false} Example
key: px_risk_cookie_max_iterations
value: 5000
```

---

**`px_debug`** `boolean` — default: false

Whether 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`**

```sh showLineNumbers={false} Example
key: px_debug
value: true
```

---

**`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.

the client connection

**`Example`**

```sh showLineNumbers={false} Example
key: px_ip_headers
value: true-client-ip, x-forwarded-for
```

---

**`px_module_enabled`** `boolean` — default: true

Whether the Enforcer module is enabled.

* `true`: Enable the module
* `false`: Disable  the module

**`Example`**

```sh showLineNumbers={false} Example
key: px_module_enabled
value: true
```

---

**`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`**

```sh showLineNumbers={false} Example
key: px_module_mode
value: active_blocking
```

---

## Optional configurations

These configurations aren't required, but you can use them to further customize the Enforcer's behavior.

### 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`**

```sh showLineNumbers={false} Example
key: px_advanced_blocking_response_enabled
value: 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`**

```sh showLineNumbers={false} Example
key: px_bypass_monitor_header
value: x-bypass-monitor
```

---

### 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

See [Runtime callbacks](#credentials-intelligence-runtime-callbacks) for more options for configuring Credentials Intelligence.

**`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`**

```sh showLineNumbers={false} Example
key: px_login_credentials_extraction_enabled
value: true
```

---

**`px_login_credentials_extraction`** `object`

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 [`set_ci_extract_credentials_fn`](#set_ci_extract_credentials_fn).

**`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!"
    }
}
```

---

**`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 [`set_ci_login_successful_fn`](#set_ci_login_successful_fn).

**`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_body_regex`** `string`

**Required** if [`login_successful_reporting_method`](#login_successful_reporting_method) is set to `"body"`. A regular expression (or string representing a regular expression) to against which the response body will be evaluated. A match indicates a successful login.

**`Example`**

```ts Example
{
    // ...
    login_successful_reporting_method: 'body',
    login_successful_body_regex: 'Welcome, [A-Za-z0-9_]+!'
    // ...
}
```

---

**`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'
    // ...
}
```

---

**`Full example`**

```json Full example
[
    {
        "path": "/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]
    }
]
```

---

**`px_credentials_intelligence_version`** `"v2" | "multistep_sso" | "both"` — default: both

The default credential hashing protocol applied to endpoints that do not specify a [`protocol`](#protocol) field.

* `"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`**

```sh showLineNumbers={false} Example
key: px_credentials_intelligence_version
value: both
```

---

**`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`**

```sh showLineNumbers={false} Example
key: px_compromised_credentials_header
value: x-ci-compromised
```

---

**`px_additional_s2s_activity_enabled`** `boolean` — default: true

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`**

```sh showLineNumbers={false} Example
key: px_additional_s2s_activity_enabled
value: 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_additional_s2s_activity_enabled`](#px_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.

**`Example`**

```sh showLineNumbers={false} Example
key: px_additional_s2s_activity_header_enabled
value: true
```

---

**`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`**

```sh showLineNumbers={false} Example
key: px_send_raw_username_on_additional_s2s_activity
value: true
```

---

**`px_login_successful_reporting_method`** `"status" | "body" | "header" | "custom"` — default: status

The default login-success detection method applied to endpoints that don't override it. See [`login_successful_reporting_method`](#login_successful_reporting_method) for the possible values.

**`Example`**

```sh showLineNumbers={false} Example
key: px_login_successful_reporting_method
value: custom
```

---

**`px_login_successful_status`** `integer[]` — default: 200

The default HTTP status codes that indicate a successful login. This takes effect when the [`px_login_successful_reporting_method`](#px_login_successful_reporting_method) is set to `status`.

**`Example`**

```sh showLineNumbers={false} Example
key: px_login_successful_status
value: 200, 202
```

---

**`px_login_successful_body_regex`** `string`

The default body regular expression that indicates a successful login. This takes effect when the [`px_login_successful_reporting_method`](#px_login_successful_reporting_method) is set to `body`.

**`Example`**

```sh showLineNumbers={false} Example
key: px_login_successful_body_regex
value: Welcome, [A-Za-z0-9_]+!
```

---

**`px_login_successful_header_name`** `string`

The default response header name that indicates a successful login. This takes effect when the [`px_login_successful_reporting_method`](#px_login_successful_reporting_method) is set to `header`.

**`Example`**

```sh showLineNumbers={false} Example
key: px_login_successful_header_name
value: x-login-successful
```

---

**`px_login_successful_header_value`** `string`

The default response header value that indicates a successful login. This takes effect when the [`px_login_successful_reporting_method`](#px_login_successful_reporting_method) is set to `header`.

**`Example`**

```sh showLineNumbers={false} Example
key: px_login_successful_header_value
value: logged-in
```

---

### 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.

See [Runtime callbacks](#cors-support-runtime-callbacks) for more options for configuring CORS support.

**`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: <ORIGIN_REQUEST_HEADER_VALUE>  
  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`**

```sh showLineNumbers={false} Example
key: px_cors_support_enabled
value: true
```

---

**`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`**

```sh showLineNumbers={false} Example
key: px_cors_preflight_request_filter_enabled
value: true
```

---

### 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`**

```sh showLineNumbers={false} Example
key: px_custom_cookie_header
value: x-custom-cookies
```

---

### 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<string>` — default: \[]

Routes or prefixes that should be enforced by HUMAN even when the Enforcer is in [monitor mode](#px_module_mode).

**`Example`**

```sh showLineNumbers={false} Example
key: px_enforced_routes
value: /enforced_route
```

---

### Extracted cookies

**`px_extracted_cookies`** `array<string>` — default: \[]

For each cookie name, the Enforcer will extract the cookie's key-value pair and add it as a new field in the **Risk API**. This lets you include additional information to HUMAN's detection mechanism if you'd like to.

**`Example`**

```sh showLineNumbers={false} Example
key: px_extracted_cookies
value: _ga, session_id
```

---

### 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.

See [Runtime callbacks](#filter-by-custom-function) for more options for filtering requests based on custom logic.

**`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`**

```sh showLineNumbers={false} Example
key: px_filter_by_extension
value: .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`**

```sh showLineNumbers={false} Example
key: px_filter_by_http_method
value: 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`**

```sh showLineNumbers={false} Example
key: px_filter_by_ip
value: 1.1.1.1, 2.2.2.2
```

---

**`px_filter_by_route`** `array of strings` — 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`.

**`Example`**

```sh showLineNumbers={false} Example
key: px_filter_by_route
value: /filtered_route
```

---

**`px_filter_by_user_agent`** `array of strings` — 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.

**`Example`**

```sh showLineNumbers={false} Example
key: px_filter_by_user_agent
value: filtered_UA
```

---

### First party

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.

**`px_first_party_enabled`** `boolean` — default: true

Whether to enable first party mode for Bot Defender or Sightline Cyberfraud Defense.

**`Example`**

```sh showLineNumbers={false} Example
key: px_first_party_enabled
value: false
```

---

### 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: false

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`**

```sh showLineNumbers={false} Example
key: px_graphql_enabled
value: true
```

---

**`px_graphql_routes`** `array<RegExp>` — 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).

**`Example`**

```sh showLineNumbers={false} Example
key: px_graphql_routes
value: ^/graphql$, ^/api/graphql$
```

---

**`px_sensitive_graphql_operation_names`** `array<string>` — 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

**`Example`**

```sh showLineNumbers={false} Example
key: px_sensitive_graphql_operation_names
value: SensitiveOperation1, SensitiveOperation2
```

---

**`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`**

```sh showLineNumbers={false} Example
key: px_sensitive_graphql_operation_types
value: mutation, subscription
```

---

**`px_graphql_keywords`** `array<string | RegExp>` — 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.

**`Example`**

```sh showLineNumbers={false} Example
key: px_graphql_keywords
value: performLogin, addToCart
```

---

**`px_graphql_body_max_length`** `integer` — default: 1048576

The maximum body prefix length in bytes that are read while parsing the GraphQL JSON body.

**`Example`**

```sh showLineNumbers={false} Example
key: px_graphql_body_max_length
value: 524288
```

---

### 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`**

```sh showLineNumbers={false} Example
key: px_data_enrichment_header_name
value: 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.

See [Hard block customization](#hard-block-customization) for more options for customizing the hard-block response.

**`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`**

```sh showLineNumbers={false} Example
key: px_css_ref
value: 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`**

```sh showLineNumbers={false} Example
key: px_js_ref
value: 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`**

```sh showLineNumbers={false} Example
key: px_custom_logo
value: https://www.example.com/custom_logo.png
```

---

### Logging

**`px_log_endpoint`** `string`

The name of the Fastly logging endpoint used by platform-specific activity delivery.

**`Example`**

```sh showLineNumbers={false} Example
key: px_log_endpoint
value: Human-Log
```

---

**`px_logger_auth_token`** `string` — required, default: ""

An alternative to the [basic logger](#px_debug) 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.

> **Note**
>
> We recommend storing this value in a [Fastly Secret Store](#sensitive-configurations). If you do, it will override the `px_logger_auth_token` value in the Config Store.

**`Example`**

```sh showLineNumbers={false} Example
key: px_logger_auth_token
value: <LOGGER_AUTH_TOKEN>
```

---

### 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`**

```sh showLineNumbers={false} Example
key: px_agentic_trust_enabled
value: true
```

---

**`px_agentic_trust_mcp_endpoint_path`** `array<string | RegExp>` — default: \["^/mcp\$"]

The MCP endpoint path used for AgenticTrust verification.

**`Example`**

```sh showLineNumbers={false} Example
key: px_agentic_trust_mcp_endpoint_path
value: ^/mcp$, ^/mcp-test1$
```

---

### 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`**

```sh showLineNumbers={false} Example
key: px_token_version
value: 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<string>` — 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.

**`Example`**

```sh showLineNumbers={false} Example
key: px_monitored_routes
value: /monitored_route
```

---

### PXHD cookie

**`px_secured_pxhd_enabled`** `boolean` — default: false

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`**

```sh showLineNumbers={false} Example
key: px_secured_pxhd_enabled
value: true
```

---

**`px_pxhd_domain`** `string`

Overrides the PXHD (`_pxhd`) cookie domain returned by the **Risk API**. Use this option when you want to set the PXHD cookie on a different domain than the one that's set by the Risk API.

**`Example`**

```sh showLineNumbers={false} Example
key: px_pxhd_domain
value: example.com
```

---

### 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`**

```sh showLineNumbers={false} Example
key: px_sensitive_headers
value: 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.

See [Runtime callbacks](#sensitive-routes-runtime-callbacks) for more options for configuring sensitive routes.

**`px_sensitive_routes`** `array<string>` — default: \[]

A list of prefixes for all routes that should be considered sensitive.

**`Example`**

```sh showLineNumbers={false} Example
key: px_sensitive_routes
value: /login, /checkout
```

---

**`px_sensitive_routes_regex`** `array<string>` — default: \[]

A list of regular expressions for all routes that should be considered sensitive.

**`Example`**

```sh showLineNumbers={false} Example
key: px_sensitive_routes_regex
value: ^/login$, ^/api/.*/checkout$
```

---

### 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`**

```sh showLineNumbers={false} Example
key: px_jwt_cookie_name
value: 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`**

```sh showLineNumbers={false} Example
key: px_jwt_cookie_user_id_field_name
value: 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`**

```sh showLineNumbers={false} Example
key: px_jwt_cookie_additional_field_names
value: 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`**

```sh showLineNumbers={false} Example
key: px_jwt_header_name
value: 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`**

```sh showLineNumbers={false} Example
key: px_jwt_header_user_id_field_name
value: 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`**

```sh showLineNumbers={false} Example
key: px_jwt_header_additional_field_names
value: exp, iss
```

---

## Runtime callbacks

Some supported features can't be expressed as Config Store values. Instead, you can register runtime callbacks in your Rust code **before** calling `px.enforce()` to enable them.

Functions are mapped to equivalent standard configuration options used in other HUMAN Enforcers.

### 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.

Registered via `set_additional_activity_handler_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXAdditionalActivityHandlerFn =
    fn(req: &Request, conf: &PXConfig, ctx: &PXContext);

pub fn set_additional_activity_handler_fn(&mut self, f: PXAdditionalActivityHandlerFn);
```

---

### CORS support \[#cors-support-runtime-callbacks]

See [CORS support](#cors-support) for Config Store options.

**`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.

Registered via `set_cors_create_custom_block_response_headers_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXCorsCustomBlockResponseHeadersFn =
    fn(req: &Request, conf: &PXConfig) -> Vec<(String, String)>;

pub fn set_cors_create_custom_block_response_headers_fn(
    &mut self,
    f: PXCorsCustomBlockResponseHeadersFn,
)
```

**`Example`**

```rust Example
// callback function to create custom CORS headers for block responses
fn cors_block_response_headers(req: &Request, _conf: &PXConfig) -> Vec<(String, String)> {
    vec![
        (
            "Access-Control-Allow-Origin".to_string(),
            req.get_header_str("Origin").unwrap_or_default().to_string(),
        ),
        (
            "Access-Control-Allow-Credentials".to_string(),
            "true".to_string(),
        ),
        (
            "Access-Control-Allow-Methods".to_string(),
            "GET, POST, OPTIONS".to_string(),
        ),
        (
            "Access-Control-Allow-Headers".to_string(),
            "Content-Type, Authorization".to_string(),
        ),
    ]
}

...

px.set_cors_create_custom_block_response_headers_fn(cors_block_response_headers);
```

---

**`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.

Registered via `set_cors_custom_preflight_handler_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXCorsCustomPreflightHandlerFn =
    fn(req: &Request, conf: &PXConfig) -> Option<Response>;
pub fn set_cors_custom_preflight_handler_fn(
    &mut self, f: PXCorsCustomPreflightHandlerFn);
```

**`Example`**

```rust Example
// callback function to handle CORS preflight requests
fn cors_preflight_handler(req: &Request, _conf: &PXConfig) -> Option<Response> {
    if !req.get_method_str().eq_ignore_ascii_case("OPTIONS")
        || !req.contains_header("Origin")
        || !req.contains_header("Access-Control-Request-Method")
    {
        return None;
    }

    let mut response_headers = HashMap::new();
    response_headers.insert(
        "Access-Control-Allow-Origin",
        req.get_header_str("Origin").unwrap_or_default(),
    );
    response_headers.insert(
        "Access-Control-Allow-Methods",
        req.get_header_str("Access-Control-Request-Method")
            .unwrap_or_default(),
    );
    response_headers.insert(
        "Access-Control-Allow-Headers",
        req.get_header_str("Access-Control-Request-Headers")
            .unwrap_or_default(),
    );
    response_headers.insert("Access-Control-Allow-Credentials", "true");
    response_headers.insert("Access-Control-Max-Age", "86400");

    let mut response = Response::new();
    response.set_status(fastly::http::StatusCode::NO_CONTENT);
    for (name, value) in response_headers {
        response.set_header(name, value);
    }

    Some(response)
}
```

---

### Credential Intelligence \[#credential-intelligence-runtime-callbacks]

See [Credentials Intelligence](#credentials-intelligence) for Config Store options.

**`extract_credentials_callback`** `object`

**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 and returns the raw credentials from the request, or `None` if neither field can be extracted.

Registered via `set_ci_extract_credentials_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXExtractCredentialsFn =
    fn(req: &Request, endpoint_index: usize) -> Option<PXRawCredentials>;

pub fn set_ci_extract_credentials_fn(&mut self, f: PXExtractCredentialsFn);
```

---

**`login_successful_custom_callback`** `string`

**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 that indicates whether the login attempt was successful.

Registered via `set_ci_login_successful_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXLoginSuccessfulFn =
    fn(resp: &Response, endpoint_index: usize) -> Option<bool>;

pub fn set_ci_login_successful_fn(&mut self, f: PXLoginSuccessfulFn);
```

---

### 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.

Registered via `set_enrich_custom_params_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXEnrichCustomParamsFn =
    fn(req: &Request, conf: &PXConfig, params: &mut PXCustomParams);

pub fn set_enrich_custom_params_fn(&mut self, f: PXEnrichCustomParamsFn);
```

---

### Enforced request callback

**`px_custom_is_enforced_request`** `function` — default: null

A custom function that accepts the incoming request and returns a boolean indicating whether the request should be enforced or not.

Registered via `set_is_enforced_request_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXIsEnforcedRequestFn = fn(req: &Request, conf: &PXConfig) -> bool;

pub fn set_is_enforced_request_fn(&mut self, f: PXIsEnforcedRequestFn);
```

---

### Filter by custom function

See [Filters](#filters) for Config Store options.

**`px_filter_by_custom_function`** `function` — default: null

> **Warning**
>
> This configuration is meant for cases that require more complex logic. We recommended you use the other [default filters](#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.

Registered via `set_is_filtered_request_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXIsFilteredRequestFn = fn(req: &Request, conf: &PXConfig) -> bool;

pub fn set_is_filtered_request_fn(&mut self, f: PXIsFilteredRequestFn);
```

---

### Hard block customization

See [HUMAN Challenge & hard block customization](#human-challenge--hard-block-customization) for Config Store options.

**`px_hardblock_custom_fn`** `function` — default: null

A runtime callback for customizing the hard-block response. This lets you serve localized HTML based on the incoming request headers, including Accept-Language.

Registered via `set_hard_block_custom`.

**`Functions definitions`**

```rust Functions definitions
pub type PXHardBlockCustomFn = fn(req: &Request, conf: &PXConfig) -> Option<Response>;

pub fn set_hard_block_custom_fn(&mut self, f: PXHardBlockCustomFn);
```

---

### Monitored request callback

**`px_custom_is_monitored_request`** `function` — default: null

A custom function that accepts the incoming request and returns a boolean indicating whether the request should be monitored or not.

Registered via `set_is_monitored_request_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXIsMonitoredRequestFn = fn(req: &Request, conf: &PXConfig) -> bool;

pub fn set_is_monitored_request_fn(&mut self, f: PXIsMonitoredRequestFn);
```

---

### Sensitive routes \[#sensitive-routes-runtime-callbacks]

See [Sensitive routes](#sensitive-routes) for Config Store options.

**`px_custom_is_sensitive_request`** `function` — default: null

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.

Registered via `set_is_sensitive_request_fn`.

**`Functions definitions`**

```rust Functions definitions
pub type PXIsSensitiveRequestFn = fn(req: &Request, conf: &PXConfig) -> bool;

pub fn set_is_sensitive_request_fn(&mut self, f: PXIsSensitiveRequestFn);
```

---