Fastly Rust Compute@Edge configuration options

Your HUMAN Application ID in the form of PX12AB34CD. You can copy this value from the HUMAN Console in Platform Settings > Applications Overview. If you have multiple applications, make sure to copy the ID of the application you want the Enforcer on.

key: px_app_id
value: PX12345678

The application’s server token needed to authorize with HUMAN’s backend. You can copy this value from the HUMAN Console in Platform Settings > Applications Overview > Click the appropriate application > Server token tab.

key: px_auth_token
value: <AUTH_TOKEN>

The secret used to encrypt and decrypt the risk cookie sent from the HUMAN Sensor. You can copy this value from the HUMAN Console in Sightline Cyberfraud Defense > Traffic Policy Overview > Click the appropriate application > Click the key > Copy value.

If you need to rotate secrets, then adjust this configuration to be an array of strings (string[]) and include the new secret and old secret. The new secret value should be the first value in the array. This prevents decryption failures.

key: px_cookie_secret
value: <COOKIE_SECRET>

The total time in milliseconds that the Enforcer will wait for the Risk API request to return before timing out and passing the request.

key: px_s2s_timeout
value: 1000

The minimum risk score that the Enforcer will block. Ranges from 0 (lowest risk) to 100 (highest risk).

key: px_blocking_score
value: 80

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.

key: px_user_agent_max_length
value: 2048

The maximum length of the risk cookie. If the value exceeds this length, then validation will fail automatically.

key: px_risk_cookie_max_length
value: 4096

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

key: px_risk_cookie_min_iterations
value: 500

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

key: px_risk_cookie_max_iterations
value: 5000

Whether the logger will generate detailed logs for debugging purposes. Not recommended for production environments.

See px_logger_auth_token for a header-based alternative.

key: px_debug
value: true 

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

key: px_ip_headers
value: true-client-ip, x-forwarded-for

Whether the Enforcer module is enabled.

• true: Enable the module
• false: Disable the module

key: px_module_enabled
value: true

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.
• active_blocking: The Enforcer will return block responses as needed.

key: px_module_mode
value: active_blocking

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

key: px_advanced_blocking_response_enabled
value: false

Activates the full blocking flow to verify the flow works as expected if a particular header is present on the request. Often used during monitor mode, where the Enforcer collects data without blocking user requests, before switching to active_blocking.

key: px_bypass_monitor_header
value: x-bypass-monitor

Whether to enable the extraction and reporting of credentials from the Enforcer for Credential Intelligence.

• true: Enable Credential Intelligence
• false: Disable Credential Intelligence

key: px_login_credentials_extraction_enabled
value: true

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.

1
{
2
    // ...
3
    path: '/sign-up',
4
    // ...
5
}

1
{
2
    // ...
3
    path: '/auth/[A-Za-z0-9]{12}/login',
4
    path_type: 'regex',
5
    // ...
6
}

1
{
2
    // ...
3
    method: 'POST',
4
    // ...
5
}

1
{
2
    // ...
3
    sent_through: 'body',
4
    // ...
5
}

1
{
2
    // ...
3
    sent_through: 'body',
4
    user_field: 'username',
5
    // ...
6
}

1
{
2
    // ...
3
    sent_through: 'body',
4
    user_field: 'username',
5
    // ...
6
}

1
{
2
    // ...
3
    protocol: 'v2',
4
    // ...
5
}

1
{
2
    // ...
3
    login_successful_reporting_method: 'status',
4
    // ...
5
}

1
{
2
    // ...
3
    login_successful_reporting_method: 'status',
4
    login_successful_statuses: [200, 202],
5
    // ...
6
}

1
{
2
    // ...
3
    login_successful_reporting_method: 'body',
4
    login_successful_body_regex: 'Welcome, [A-Za-z0-9_]+!'
5
    // ...
6
}

1
{
2
    // ...
3
    login_successful_reporting_method: 'header',
4
    login_successful_header_name: 'x-login-successful'
5
    // ...
6
}

1
{
2
    // ...
3
    login_successful_reporting_method: 'header',
4
    login_successful_header_name: 'x-user-status',
5
    login_successful_header_value: 'logged-in'
6
    // ...
7
}

1
[
2
    {
3
        "path": "/login",
4
        "path_type": "regex",
5
        "method": "POST",
6
        "sent_through": "body",
7
        "user_field": "username",
8
        "pass_field": "password",
9
        "login_successful_reporting_method": "status",
10
        "login_successful_statuses": [200, 202]
11
    }
12
]

The default credential hashing protocol applied to endpoints that do not specify a 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.

key: px_credentials_intelligence_version
value: both

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.

key: px_compromised_credentials_header
value: x-ci-compromised

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.

key: px_additional_s2s_activity_enabled
value: 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 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.

key: px_additional_s2s_activity_header_enabled
value: true

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.

key: px_send_raw_username_on_additional_s2s_activity
value: true

The default login-success detection method applied to endpoints that don’t override it. See login_successful_reporting_method for the possible values.

key: px_login_successful_reporting_method
value: custom

The default HTTP status codes that indicate a successful login. This takes effect when the px_login_successful_reporting_method is set to status.

key: px_login_successful_status
value: 200, 202

The default body regular expression that indicates a successful login. This takes effect when the px_login_successful_reporting_method is set to body.

key: px_login_successful_body_regex
value: Welcome, [A-Za-z0-9_]+!

The default response header name that indicates a successful login. This takes effect when the px_login_successful_reporting_method is set to header.

key: px_login_successful_header_name
value: x-login-successful

The default response header value that indicates a successful login. This takes effect when the px_login_successful_reporting_method is set to header.

key: px_login_successful_header_value
value: logged-in

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 configuration, which lets you customize the block response headers via a custom function.
• Activates the px_cors_preflight_request_filter_enabled and px_cors_custom_preflight_handler configurations, which lets you filter and custom handle preflight requests.

key: px_cors_support_enabled
value: true

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

key: px_cors_preflight_request_filter_enabled
value: true

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.

key: px_custom_cookie_header
value: x-custom-cookies

An array of routes or prefixes that should be enforced by HUMAN even when the Enforcer is in monitor mode.

key: px_enforced_routes
value: /enforced_route

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.

key: px_extracted_cookies
value: _ga, session_id

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.

key: px_filter_by_extension
value: .css, .js, .png

Filters out requests with the specified HTTP method to avoid unnecessary traffic in the Enforcer verification flow.

key: px_filter_by_http_method
value: OPTIONS, DELETE

Filters out requests with the specified IP address to avoid unnecessary traffic in the Enforcer verification flow.

key: px_filter_by_ip
value: 1.1.1.1, 2.2.2.2

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.

key: px_filter_by_route
value: /filtered_route

Filters out requests with the specified user agent to avoid unnecessary traffic in the Enforcer verification flow.

key: px_filter_by_user_agent
value: filtered_UA

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

key: px_first_party_enabled
value: 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 will have their bodies parsed for GraphQL operations.

• true: Enable GraphQL support
• false: Disable GraphQL support

key: px_graphql_enabled
value: true

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

key: px_graphql_routes
value: ^/graphql$, ^/api/graphql$

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

key: px_sensitive_graphql_operation_names
value: SensitiveOperation1, SensitiveOperation2

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.

key: px_sensitive_graphql_operation_types
value: mutation, subscription

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 for more information.

key: px_graphql_keywords
value: performLogin, addToCart

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

key: px_graphql_body_max_length
value: 524288

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.

key: px_data_enrichment_header_name
value: x-human-data-enrichment

A way to include a custom CSS file to the block page.

Maps to {{{{cssRef}}}} in the block page template.

key: px_css_ref
value: https://www.example.com/custom_style.css

A way to include custom JavaScript to the block page. This script will run after the default JavaScript scripts.

Maps to {{{{jsRef}}}} in the block page template.

key: px_js_ref
value: https://www.example.com/custom_script.js

Adds a custom logo to the HUMAN Challenge block page via URL.

Maps to {{{{customLogo}}}} in the block page template.

key: px_custom_logo
value: https://www.example.com/custom_logo.png

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

key: px_log_endpoint
value: Human-Log

An alternative to the basic logger 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 to recieve your token.

key: px_logger_auth_token
value: <LOGGER_AUTH_TOKEN>

Whether to enable AgenticTrust verification for MCP requests.

• true: Enable MCP verification
• false: Disable MCP verification

key: px_agentic_trust_enabled
value: true

The MCP endpoint path used for AgenticTrust verification.

key: px_agentic_trust_mcp_endpoint_path
value: /mcp/

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.

key: px_token_version
value: 3

A list of endpoints to be monitored rather than blocked by the Enforcer, even when the Enforcer is in active_blocking mode.

key: px_monitored_routes
value: /monitored_route

The PX Hashed Data (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 is added when setting the PXHD cookie.

See Use of cookies & web storage for more information.

key: px_secured_pxhd_enabled
value: true

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.

key: px_sensitive_headers
value: x-sensitive-token

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

key: px_sensitive_routes
value: /login, /checkout

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

key: px_sensitive_routes_regex
value: ^/login$, ^/api/.*/checkout$

The name of the cookie that contains the JWT token that HUMAN should extract user identifiers from.

key: px_jwt_cookie_name
value: auth

The field name in the JWT object, extracted from the JWT cookie, that contains the user ID to be extracted and reported.

key: px_jwt_cookie_user_id_field_name
value: nameID

The field names in the JWT object, extracted from the JWT cookie, that should be extracted and reported in addition to the user ID.

key: px_jwt_cookie_additional_field_names
value: exp, iss

The name of the header that contains the JWT token that HUMAN should extract user identifiers from.

key: px_jwt_header_name
value: x-jwt-authorization

The field name in the JWT object, extracted from the JWT header, that contains the user ID to be extracted and reported.

key: px_jwt_header_user_id_field_name
value: sub

The field names in the JWT object, extracted from the JWT header, that should be extracted and reported in addition to the user ID.

key: px_jwt_header_additional_field_names
value: exp, iss

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.

1
pub type PXAdditionalActivityHandlerFn =
2
    fn(req: &Request, conf: &PXConfig, ctx: &PXContext);
3
4
pub fn set_additional_activity_handler_fn(&mut self, f: PXAdditionalActivityHandlerFn);

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.

1
pub type PXCorsCustomBlockResponseHeadersFn =
2
    fn(req: &Request, conf: &PXConfig) -> Vec<(String, String)>;
3
4
pub fn set_cors_create_custom_block_response_headers_fn(
5
    &mut self,
6
    f: PXCorsCustomBlockResponseHeadersFn,
7
)

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

1
pub type PXCorsCustomPreflightHandlerFn =
2
    fn(req: &Request, conf: &PXConfig) -> Option<Response>;
3
pub fn set_cors_custom_preflight_handler_fn(
4
    &mut self, f: PXCorsCustomPreflightHandlerFn);

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

1
pub type PXExtractCredentialsFn =
2
    fn(req: &Request, endpoint_index: usize) -> Option<PXRawCredentials>;
3
4
pub fn set_ci_extract_credentials_fn(&mut self, f: PXExtractCredentialsFn);

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

1
pub type PXLoginSuccessfulFn =
2
    fn(resp: &Response, endpoint_index: usize) -> Option<bool>;
3
4
pub fn set_ci_login_successful_fn(&mut self, f: PXLoginSuccessfulFn);

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.

1
pub type PXEnrichCustomParamsFn =
2
    fn(req: &Request, conf: &PXConfig, params: &mut PXCustomParams);
3
4
pub fn set_enrich_custom_params_fn(&mut self, f: PXEnrichCustomParamsFn);

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.

1
pub type PXIsFilteredRequestFn = fn(req: &Request, conf: &PXConfig) -> bool;
2
3
pub fn set_is_filtered_request_fn(&mut self, f: PXIsFilteredRequestFn);

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.

1
pub type PXIsSensitiveRequestFn = fn(req: &Request, conf: &PXConfig) -> bool;
2
3
pub fn set_is_sensitive_request_fn(&mut self, f: PXIsSensitiveRequestFn);