Fastly VCL v12 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.

1
# PX_CONFIGS
2
table px_configs {
3
    "px_app_id": "<APP_ID>",
4
    # ...
5
}

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.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_auth_token": "<AUTH_TOKEN>",
5
    # ...
6
}

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 the new generated cookie secret, then add an additional field name, px_cookie_secret_old, that holds the previous cookie secret value.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_cookie_secret": "<COOKIE_SECRET>",
5
    # ...
6
}

The base URL for the HUMAN SAPI (Risk API and related calls). If empty, the Enforcer uses the default host for your Application ID.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_backend_url": "sapi-<APP_ID>.perimeterx.net",
5
    # ...
6
}

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

1
# PX_CONFIGS
2
backend PX_API {
3
    # ...
4
    .connect_timeout = 2000ms;
5
    .first_byte_timeout = 2000ms;
6
    .between_bytes_timeout = 2000ms;
7
    # ...
8
}

The severity at which the logger will output logs.

• none: The logger will not generate any logs.
• error: The logger will only generate logs on fatal errors.
• debug: The logger will generate detailed logs for debugging purposes. Not recommended for production environments.

See px_logger_auth_token for a header-based alternative.

When set to error, logs are sent to the endpoint named by px_error_syslog_name. When set to debug, logs are sent to the endpoint named by px_debug_syslog_name.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_logger_severity": "debug",
5
    # ...
6
}

By default, the Enforcer reports the value from the Fastly-Client-IP header. If that value is inaccurate, implement this subroutine to return the true client IP from a trusted custom header. Returning an empty string falls back to Fastly-Client-IP.

1
# PX_CUSTOM
2
sub px_custom_client_ip_extraction STRING {
3
    if (req.http.true-client-ip) {
4
        return req.http.true-client-ip;
5
    }
6
    return "";
7
}

Whether the Enforcer module is enabled.

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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_module_enabled": "false",
5
    # ...
6
}

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.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_module_mode": "active_blocking",
5
    # ...
6
}

Fastly VCL cannot automatically report all request headers on async activities. Return a string of additional headers to include. Each header must use the form ",{%22name%22: %22<header name>%22, %22value%22: " if(req.http.<header name>, "%22" json.escape(req.http.<header name>) "%22", "null") "}".

1
# PX_CUSTOM
2
sub px_custom_activity_headers STRING {
3
    declare local var.ret STRING;
4
    set var.ret =
5
        ",{%22name%22: %22my-header%22, %22value%22: " if(req.http.my-header, "%22" json.escape(req.http.my-header) "%22", "null") "}"
6
        ",{%22name%22: %22my-header-1%22, %22value%22: " if(req.http.my-header-1, "%22" json.escape(req.http.my-header-1) "%22", "null") "}";
7
    return var.ret;
8
}

Whether to invoke the px_custom_additional_activity_handler subroutine.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_additional_activity_handler_enabled": "true",
5
    # ...
6
}

A custom subroutine that runs after the Enforcer prepares the page_requested or block activity 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 so the application can read it and apply its own logic. HUMAN metadata is available on req.http.px-ctx. This subroutine is called in vcl_recv.

1
# PX_CUSTOM
2
sub px_custom_additional_activity_handler {
3
    declare local var.score STRING;
4
    set var.score = if(req.http.px-ctx:pass-reason, "0", "100");
5
    log "syslog " req.service_id " CustomLoggingEndpoint :: Score: " var.score ", Data Enrichment: " req.http.px-ctx:data-enrichment;
6
}

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.

• true: Enable ABR
• false: Disable ABR

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_advanced_blocking_response_enabled": "false",
5
    # ...
6
}

Due to Fastly size limits, large Risk API requests may return HTTP 413. By default, the Enforcer fails open. When enabled, those requests are blocked instead.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_block_size_exceeded_15k_headers_size": "true",
5
    # ...
6
}

Whether to include px-ctx:block-result with value "0" (pass) or "1" (block) on origin requests. Useful while testing in monitor mode.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_add_block_result_header": "true",
5
    # ...
6
}

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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_bypass_monitor_header": "x-bypass-monitor-mode",
5
    # ...
6
}

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_custom_cors_set_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_custom_cors_preflight_handler configurations, which lets you filter and custom handle preflight requests.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_cors_support_enabled": "true",
5
    # ...
6
}

Whether to invoke px_custom_cors_set_custom_block_response_headers.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_cors_create_custom_block_response_headers_enabled": "true",
5
    # ...
6
}

If the default CORS response headers are not sufficient, use this subroutine to customize the headers added to block responses resulting from CORS requests. If this subroutine is defined, the default CORS block headers are not added. Only the headers you set on obj are included.

1
# PX_CUSTOM
2
sub px_custom_cors_set_custom_block_response_headers {
3
    set obj.http.Access-Control-Allow-Origin = req.http.Origin;
4
    set obj.http.Access-Control-Allow-Credentials = "true";
5
    set obj.http.Access-Control-Allow-Methods = "GET, POST, OPTIONS";
6
    set obj.http.Access-Control-Allow-Headers = "Content-Type, Authorization";
7
}

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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_cors_preflight_request_filter_enabled": "true",
5
    # ...
6
}

Whether to invoke px_custom_cors_preflight_handler.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_cors_preflight_handler_enabled": "true",
5
    # ...
6
}

A custom subroutine for handling CORS preflight requests. Use it to return a customized preflight response before enforcement. px_custom_cors_preflight_handler is invoked prior to determining whether to filter the request based on px_cors_preflight_request_filter_enabled. This lets you return customized responses for preflight requests that meet certain conditions and filter those that do not.

1
# PX_CUSTOM
2
sub px_custom_cors_preflight_handler {
3
    set obj.status = 204;
4
    set obj.http.Access-Control-Allow-Origin = req.http.Origin;
5
    set obj.http.Access-Control-Allow-Methods = req.method;
6
    set obj.http.Access-Control-Allow-Headers = req.http.Access-Control-Request-Headers;
7
    set obj.http.Access-Control-Allow-Credentials = "true";
8
    set obj.http.Access-Control-Max-Age = "86400";
9
}

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

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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_login_credentials_extraction_enabled": "true",
5
    # ...
6
}

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
# PX_CUSTOM
2
table px_login_credentials_extraction {
3
    "path_0": "/login",
4
    "protocol_0": "v2",
5
    "method_0": "post",
6
    "sent_through_0": "body",
7
    "pass_field_0": "password",
8
    "user_field_0": "username",
9
10
    "path_1": "/sign-up",
11
    "protocol_1": "multistep_sso",
12
    "method_1": "post",
13
    "sent_through_1": "custom",
14
}

1
# PX_CUSTOM
2
table px_login_credentials_extraction {
3
    # ...
4
    "path_0": "/sign-up",
5
    # ...
6
}

1
# PX_CUSTOM
2
table px_login_credentials_extraction {
3
    # ...
4
    "method_0": "post",
5
    # ...
6
}

1
# PX_CUSTOM
2
table px_login_credentials_extraction {
3
    # ...
4
    "sent_through_0": "body",
5
    # ...
6
}

1
# PX_CUSTOM
2
table px_login_credentials_extraction {
3
    # ...
4
    "sent_through_0": "body",
5
    "user_field_0": "username",
6
    # ...
7
}

1
# PX_CUSTOM
2
table px_login_credentials_extraction {
3
    # ...
4
    "sent_through_0": "body",
5
    "pass_field_0": "password",
6
    # ...
7
}

1
# PX_CUSTOM
2
table px_login_credentials_extraction {
3
    # ...
4
    "protocol_0": "v2",
5
    # ...
6
}

Returns the credential endpoint suffix (for example _0 or _1) that matches the request path for px_login_credentials_extraction. Use this subroutine for exact or regex path matching.

1
# PX_CUSTOM
2
sub px_custom_is_login_request STRING {
3
    if (req.url.path == table.lookup(px_login_credentials_extraction, "path_0")) {
4
        return "_0";
5
    } else if (req.url.path ~ "^/sign-up") {
6
        return "_1";
7
    }
8
}

Required if sent_through is set to "custom". A custom credential extraction subroutine that returns the raw credentials from the request. Use req.http.px-creds:endpoint-index to distinguish endpoints. Set req.http.px-creds:raw-username and req.http.px-creds:raw-password. If neither the username nor the password can be extracted, leave both unset.

1
# PX_CUSTOM
2
sub px_custom_login_extraction_callback {
3
    declare local var.username STRING;
4
    declare local var.password STRING;
5
6
    if (req.http.px-creds:endpoint-index == "_1") {
7
        # set var.username and var.password from the request
8
    }
9
10
    if (var.username) {
11
        set req.http.px-creds:raw-username = var.username;
12
    }
13
    if (var.password) {
14
        set req.http.px-creds:raw-password = var.password;
15
    }
16
}

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 px_login_successful_status.
• "header": The Enforcer will determine if the login request was successful when resp.http.x-px-login-successful is "1".
• "custom": The Enforcer will determine if the login request was successful by invoking px_custom_set_login_successful_response_header.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_login_successful_reporting_method": "custom",
5
    # ...
6
}

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

Fastly VCL supports a single status code. For multiple status codes, use custom reporting with px_custom_set_login_successful_response_header.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_login_successful_status": "202",
5
    # ...
6
}

Required if px_login_successful_reporting_method is set to "custom". A custom subroutine that inspects the HTTP response and indicates whether the login attempt was successful. Return "1" if the login succeeded or "0" otherwise. Invoked during vcl_deliver.

1
# PX_CUSTOM
2
sub px_custom_set_login_successful_response_header STRING {
3
    if (resp.http.custom-login-header == "login_successful") {
4
        return "1";
5
    }
6
    return "0";
7
}

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.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_send_raw_username_on_additional_s2s_activity": "true",
5
    # ...
6
}

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. Enabling this configuration disables automatic sending of additional_s2s activity.

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.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_additional_s2s_activity_header_enabled": "true",
5
    # ...
6
}

Whether to append compromised_credentials=true to the origin request URL when compromised credentials are identified. Unlike header-based signaling on other Enforcers, Fastly VCL can surface compromised credentials through the request query string.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_credentials_intelligence_query_string": "true",
5
    # ...
6
}

When px_credentials_intelligence_query_string is enabled and a successful login used compromised credentials, set the client response status to this value.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_compromised_credentials_returned_status_response": "401",
5
    # ...
6
}

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.

Prefer configuring protocol per endpoint in px_login_credentials_extraction.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_credentials_intelligence_version": "v2",
5
    # ...
6
}

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.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_custom_cookie_header": "custom-human-cookies",
5
    # ...
6
}

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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_first_party_enabled": "false",
5
    # ...
6
}

Sets a custom prefix for first party routes to use in addition to the default prefix. By default, first party endpoints always begin with the Application ID without the initial “PX”. For example, if the ID is PX12345678, then all first party routes will take the form /12345678/*.

When configured, the Enforcer will respond to first party requests with endpoints matching the following patterns:

• /<px_custom_first_party_prefix>/init.js
• /<px_custom_first_party_prefix>/xhr/*
• /<px_custom_first_party_prefix>/captcha/*

If empty, the configuration will use the default as described above.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_custom_first_party_prefix": "/custom-prefix",
5
    # ...
6
}

Customizes the entire first party Sensor script endpoint. By default, for an Application ID PX12345678, the first party endpoint is /12345678/init.js.

In addition to responding to requests that match this configured route, the Enforcer will also proxy first party requests that match the default pattern (/12345678/init.js) and patterns according to the custom prefix (/<px_custom_first_party_prefix>/init.js) if one is configured.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_custom_first_party_sensor_endpoint": "/human_sensor",
5
    # ...
6
}

Customizes the first party XHR endpoint. By default, for an Application ID PX12345678, the first party XHR endpoint is /12345678/xhr.

In addition to responding to requests that match this configured route, the Enforcer will also proxy first party requests that match the default pattern (/12345678/xhr/*) and patterns according to the custom prefix (/<px_custom_first_party_prefix>/xhr/*) if one is configured.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_custom_first_party_xhr_endpoint": "/human_xhr",
5
    # ...
6
}

Customizes the first party CAPTCHA endpoint. By default, for an Application ID PX12345678, the first party CAPTCHA endpoint is /12345678/captcha.

In addition to responding to requests that match this configured route, the Enforcer will also proxy first party requests that match the default pattern (/12345678/captcha/*) and patterns according to the custom prefix (/<px_custom_first_party_prefix>/captcha/*) if one is configured.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_custom_first_party_captcha_endpoint": "/human_captcha",
5
    # ...
6
}

Modifies first party responses in vcl_deliver using the client response object.

1
# PX_CUSTOM
2
sub px_custom_first_party_response_modifier {
3
    unset resp.http.Access-Control-Allow-Origin;
4
    set resp.http.Strict-Transport-Security = "max-age=86400";
5
}

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. There is a limit of 10 custom parameters (1–10). Set them on request headers named px-custom-param:<NUMBER>. Custom parameters must also be configured in the HUMAN Portal.

1
# PX_CUSTOM
2
sub px_custom_add_custom_parameters {
3
    set req.http.px-custom-param:1 = "test1";
4
    set req.http.px-custom-param:2 = "test2";
5
    set req.http.px-custom-param:3 = "3";
6
}

A custom subroutine that lets you define which requests should be enforced based on custom logic, even when the Enforcer is in monitor mode.

• Returns true: The request should be enforced.
• Returns false (default): The request should proceed with the usual enforcement flow.

1
# PX_CUSTOM
2
sub px_custom_enforced_routes BOOL {
3
    if (req.url.path ~ {"^/enforced|^/checkout"}) {
4
        return true;
5
    }
6
    return false;
7
}

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.

Extract cookie values onto bereq.http.X-PX-<COOKIE_NAME> headers for HUMAN backend requests.

1
# PX_CUSTOM
2
sub px_custom_extracted_cookies {
3
    if (req.http.cookie:session_id && req.http.cookie:session_id != "") {
4
        set bereq.http.X-PX-session_id = req.http.cookie:session_id;
5
    }
6
}

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.

1
# PX_CUSTOM
2
sub px_custom_filter_by_extension BOOL {
3
    if ((req.request == "GET" || req.request == "HEAD") && req.url.ext ~ "^(css|bmp|tif|ttf|docx|woff2|js|pict|tiff|eot|xlsx|csv|eps|woff|xls|jpeg|jpg|doc|ejs|otf|pptx|gif|pdf|swf|svg|ps|ico|pls|midi|svgz|class|png|ppt|mid|webp|jar)$") {
4
        return true;
5
    }
6
    return false;
7
}

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

1
# PX_CUSTOM
2
sub px_custom_filter_by_http_method BOOL {
3
    if (req.request ~ "(?i)^(OPTIONS|TRACE)$") {
4
        return true;
5
    }
6
    return false;
7
}

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

1
# PX_CUSTOM
2
acl Filtered_IPs {
3
    "123.123.123.123";
4
    "12.12.12.0"/24;
5
}
6
7
sub px_custom_filter_by_ip BOOL {
8
    if (req.http.Fastly-Client-IP ~ Filtered_IPs) {
9
        return true;
10
    }
11
    return false;
12
}

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.

1
# PX_CUSTOM
2
sub px_custom_filter_by_route BOOL {
3
    if (req.url.path ~ {"^/health|^/static/"}) {
4
        return true;
5
    }
6
    return false;
7
}

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.

1
# PX_CUSTOM
2
sub px_custom_filter_by_user_agent BOOL {
3
    if (req.http.User-Agent ~ {"Filtered_UA"}) {
4
        return true;
5
    }
6
    return false;
7
}

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_custom_is_graphql_route will have their bodies parsed for GraphQL operations.

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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_graphql_enabled": "false",
5
    # ...
6
}

A custom subroutine that returns whether the request should be considered a GraphQL route.

• Returns true: HUMAN checks for sensitive GraphQL operations as specified in px_sensitive_graphql_operation_names and px_sensitive_graphql_operation_types.
• Returns false (default): The Enforcer won’t attempt to extract GraphQL data.

1
# PX_CUSTOM
2
sub px_custom_is_graphql_route BOOL {
3
    if (req.url.path ~ {"/graphql"}) {
4
        return true;
5
    }
6
    return false;
7
}

A space-separated 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 names as sensitive to ensure more stringent protection.

If one or more GraphQL operations has a name matching this list, the Enforcer will trigger a Risk API call even if the request contains a valid, unexpired cookie.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_sensitive_graphql_operation_names": "SensitiveOperation1 SensitiveOperation2",
5
    # ...
6
}

A space-separated 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.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_sensitive_graphql_operation_types": "mutation subscription",
5
    # ...
6
}

A custom subroutine that returns a boolean indicating whether the request should be treated as sensitive given the GraphQL data that was extracted by the enforcer. If it returns true, the Enforcer will trigger a Risk API call even if the request contains a valid, unexpired cookie. Extracted values are available on:

• req.http.px-graphql:operation-type: The GraphQL operation type (query, mutation, subscription) on the request. See px_sensitive_graphql_operation_types for more information.
• req.http.px-graphql:operation-name: The GraphQL operation name on the request. See px_sensitive_graphql_operation_names for more information.

1
# PX_CUSTOM
2
sub px_custom_check_sensitive_graphql_operation BOOL {
3
    if (req.http.px-graphql:operation-type ~ "mutation" || req.http.px-graphql:operation-name ~ "SensitiveOperation") {
4
        return true;
5
    }
6
    return false;
7
}

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.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_data_enrichment_header_name": "x-px-data-enrichment",
5
    # ...
6
}

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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_css_ref": "https://example.com/custom.css",
5
    # ...
6
}

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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_js_ref": "https://example.com/custom.js",
5
    # ...
6
}

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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_custom_logo": "https://example.com/logo.png",
5
    # ...
6
}

Returns a string containing custom HTML for the HUMAN Challenge block page. Block page template values are available on req.http.X-PX-template:*.

1
# PX_CUSTOM
2
sub px_custom_block_page_content STRING {
3
    declare local var.block-page-content STRING;
4
    set var.block-page-content = {"<!DOCTYPE html><html><body>Access denied</body></html>"};
5
    return var.block-page-content;
6
}

Overrides the default web block response status and headers.

1
# PX_CUSTOM
2
sub px_custom_web_block_page_response {
3
    set obj.status = 403;
4
    set obj.response = "Forbidden";
5
    set obj.http.Content-Type = "text/html";
6
}

Overrides the default rate-limit block response.

1
# PX_CUSTOM
2
sub px_custom_rate_limit_block_page {
3
    set obj.status = 429;
4
    set obj.response = "Too Many Requests";
5
    set obj.http.Content-Type = "text/html";
6
}

Overrides the default Advanced Blocking Response (ABR) JSON block response status and headers.

1
# PX_CUSTOM
2
sub px_custom_create_advanced_blocking_response {
3
    set obj.status = 403;
4
    set obj.response = "Forbidden";
5
    set obj.http.Content-Type = "application/json";
6
}

Name of the logging endpoint used to send asynchronous activities.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_async_activities_logger": "Human-Async-Activities",
5
    # ...
6
}

Name of the logging endpoint used to send telemetry activities.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_telemetry_activity_logger": "Human-Telemetry",
5
    # ...
6
}

Name of the logging endpoint for debug logs when px_logger_severity is debug.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_debug_syslog_name": "Human-Debug",
5
    # ...
6
}

Name of the logging endpoint for error logs when px_logger_severity is error.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_error_syslog_name": "Human-Error",
5
    # ...
6
}

When logger severity is debug, one out of every N requests generates logs, where N is this value. "1" logs every request (1/1), while "100" logs about 1% of requests (1/100).

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_debug_probability": "100",
5
    # ...
6
}

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

• Returns true: The request should behave as if the Enforcer is in monitor mode, even when the module mode is active_blocking.
• Returns false (default): The request should proceed with the usual enforcement flow.

1
# PX_CUSTOM
2
sub px_custom_monitored_routes BOOL {
3
    if (req.url.path ~ {"^/monitored|^/experiments/"}) {
4
        return true;
5
    }
6
    return false;
7
}

Adjusts HUMAN configuration based on runtime values by modifying req.http.px-cfg header fields. See the PX VCL file for available px-cfg keys.

1
# PX_CUSTOM
2
sub px_override_configs {
3
    if (client.geo.country_code == "GB") {
4
        set req.http.px-cfg:css-ref = "https://example.co.uk/style.css";
5
    }
6
}

Whether to invoke px_custom_pre_clean.

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_enable_pre_clean": "true",
5
    # ...
6
}

Runs immediately before HUMAN metadata headers are removed from the backend request.

1
# PX_CUSTOM
2
sub px_custom_pre_clean {
3
    set bereq.http.X-Human-Score = if(req.http.px-ctx:pass-reason, "0", "100");
4
    set bereq.http.X-Human-Uuid = req.http.px-ctx:uuid;
5
}

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 is added when setting the PXHD cookie.

See 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

1
# PX_CONFIGS
2
table px_configs {
3
    # ...
4
    "px_secured_pxhd_enabled": "true",
5
    # ...
6
}