Configuration Options

🚧
PII (Personally Identifiable Information) Anonymization
Personally Identifiable Information (PII) is information that can be used on its own or with other information to identify a single person, or to identify an individual in context.
It is important for us to keep personal private information out of our servers. Therefore, by default, we do not send the request body and cookies to HUMAN backend servers, the entire communication is based on headers data.
PII is not a recommended setting. If PII is essential for your organization, contact HUMAN Support.
When PII is enabled, HUMAN does not store a client’s full IP information (Client IP, HTTP Headers). In IPv4 this is done by zeroing 4th IP octet (for example, the IP 1.2.3.4 will be stored as 1.2.3.0). In IPv6 this is done by zeroing the last four (4) octets (for example, the IP 1:2:3:4:1:2:3:4 will be stored as 1:2:3:4:1:2:3:0).
Removing the IP's last octet can result small reduction of detection capability, usually for the models and signatures that are based on IPs.

Module Enabled

A boolean flag to enable/disable the HUMAN Enforcer.

Default: Off

<VirtualHost *:80>
    ...
    px_enabled On
    ...
</VirtualHost>

Monitor Mode/Block Mode

By default, the HUMAN plugin is set to Monitor Only mode. To active blocking mode, set the px_block_enabled property to On.

Default: Off

<VirtualHost *:80>
    ...
    px_block_enabled On
    ...
</VirtualHost>

Blocking Score

Sets the minimum blocking score of a request. Do not change this value without consulting with a HUMAN support engineer.

Possible values:

Any integer between 0 and 100.

Default: 100

<VirtualHost *:80>
    ...
    px_blocking_score 100
    ...
</VirtualHost>

Debug Mode

A boolean flag to enable/disable the debug log messages.

Default: Off

<VirtualHost *:80>
    ...
    px_debug On
    ...
</VirtualHost>

Sensitive Routes

A list of route prefixes/suffixes that trigger a server call to HUMAN servers every time the route is called, regardless of viewing history.

Default: Empty list

<VirtualHost *:80>
    ...
    px_sensitive_routes_prefix "/login" "/user/profile"
    px_sensitive_routes_suffix "/download"
    ...
</VirtualHost>

Allowlist Routes

Allowing (bypassing enforcement) can be configured on different aspects of the request, ranging from URI to IP addresses and user agents. The rules are OR based.

Default: Empty list

<VirtualHost *:80>
    ...
    # Filters requests to `/api_server_full?data=1`, but not to `/api_server?data=1`
    px_whitelist_uri_full "/api_server_full?data=1"

    # Filters requests to `/api_server_full?data=1` but not to `/full_api_server?data=1`
    px_whitelist_uri_prefixes "/api_server"

    # Filters request to `/result.json` but not to `/result.js`
    px_whitelist_uri_suffixes ".json"

    # Filters requests coming from any of the IPs listed. Accepts either a full IPV4 address or a CIDR (192.168.0.0/16):
    px_whitelist_ip_addresses "10.0.0.15" "192.168.0.0/16"

    # Filters all requests matching this exact UA.
    px_whitelist_ua_full "Mozilla/5.0 (compatible; pingbot/2.0; http://www.pingdom.com/)"

    # Filters requests containing the provided string in their UA
    px_whitelist_ua_sub "GoogleCloudMonitoring"
    ...
</VirtualHost>

Enabled Routes

Allows you to define a set of routes on which the plugin will be active. An empty list sets all routes in the application as active.

Default: Empty list (all routes are active)

<VirtualHost *:80>
    ...
    # The plugin will be active only on `/search` and `/products` route prefixes.
    px_enabled_routes "/search" "/products"
    ...
</VirtualHost>

Sensitive Headers

A list of headers that are not sent to HUMAN servers on server-to-server API calls.

Default: "cookie" "cookies"

<VirtualHost *:80>
    ...
    px_sensitive_headers "x-px-auth" "x-px-key"
    ...
</VirtualHost>

IP Headers

A list of trusted headers that specify an IP to be extracted.

Default: Empty list

<VirtualHost *:80>
    ...
    px_ip_headers "X-Forwarded-For"
    ...
</VirtualHost>

Enrich Custom Parameters

A list of up to 10 header keys that allows you to send up to 10 custom parameters back to HUMAN servers. The parameters should be passed according to the correct order (1-10). Skipping is possible using an empty string (i.e "header1" "header2" "" "header4").

Default: Empty list

<VirtualHost *:80>
    ...
    px_custom_parameters "x-user-id" "x-vid"
    ...
</VirtualHost>

Score Header

A set of properties configuring sending the HUMAN score on upstream and/or downstream headers.

Default: Off / empty string

<VirtualHost *:80>
    ...
    # enables/disables sending score on a header
    px_score_header_enabled On

    # sets a header name to send the score upstream
    px_upstream_score_header_name "x-px-upstream-score"

    # sets a header name to send the score on the response
    px_score_header_name "x-px-score"
    ...
</VirtualHost>

API Timeout

Controls the timeout property for HUMAN requests. Times are in MS.

Default: 1000

<VirtualHost *:80>
    ...
    px_s2s_timeout 750
    ...
</VirtualHost>

Allowed Cookies

A list of cookie names that are allowed to be sent to HUMAN servers on server-to-server calls.

Default: Empty list

<VirtualHost *:80>
    ...
    px_allowed_cookies "SID" "NID"
    ...
</VirtualHost>

Advanced Blocking Response Flag

Enables/disables the Advanced Blocking Response functionality.

Default: Off

<VirtualHost *:80>
    ...
    px_enable_json_response On
    ...
</VirtualHost>

CSS Ref

Modifies a custom CSS by adding the px_css_ref property and providing a valid URL to the CSS.

Default: Empty

<VirtualHost *:80>
    ...
    px_css_ref "http://www.example.com/style.css"
    ...
</VirtualHost>

JS Ref

Adds a custom JS file by adding the px_js_ref property and providing the JS file that is loaded with the block page.

Default: Empty

<VirtualHost *:80>
    ...
    px_js_ref "https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"
    ...
</VirtualHost>

Custom Logo

The logo is displayed at the top of the the block page.
Max-height = 150px, Width = auto.

Default: Empty

<VirtualHost *:80>
    ...
    px_custom_logo "http://www.example.com/logo.png"
    ...
</VirtualHost>

Test Block Flow on Monitoring Mode

Allows you to test an enforcer’s blocking flow while you are still in Monitor Mode.

When the header name is set (eg. x-px-block) and the value is set to 1, when there is a block response (for example, from using a User-Agent header with the value of PhantomJS/1.0) the Monitor Mode is bypassed and full block mode is applied. If one of the conditions is missing you will stay in Monitor Mode. This is done per request.
To stay in Monitor Mode, set the header value to 0.

Default: Empty

<VirtualHost *:80>
    ...
    px_bypass_monitor_header "x-px-block"
    ...
</VirtualHost>

Filter By Extension

An array of extensions that are always filtered and not validated by the HUMAN Enforcer. Requests with path extensions matching these configured patterns will always be allowed to pass the HUMAN Enforcer.

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'

<VirtualHost *:80>
    ...
    px_filter_by_extension ".jpeg" ".gif" ".png"
    ...
</VirtualHost>

Filter By HTTP Method

An array of strings that represent HTTP methods that are always filtered and not validated by the HUMAN Enforcer. Requests with HTTP methods matching these will always be allowed to pass the HUMAN Enforcer.

Default: Empty list

<VirtualHost *:80>
    ...
    px_filter_by_http_method "post"
    ...
</VirtualHost>

Custom First Party Sensor Endpoint

The default first party endpoint to retrieve the HUMAN sensor is /<app_id_without_PX>/init.js. In certain cases (adblockers, etc.) it may be beneficial to change this endpoint name to a different value. You can do this by configuring a custom endpoint name using this configuration.

<VirtualHost *:80>
    ...
    px_custom_first_party_sensor_endpoint "/botdefense"
    ...
</VirtualHost>

You should also modify the snippet on the HTML pages served to refer to this custom endpoint.

// JS snippet code

(function(){
    // Custom parameters
    // window._pxParam1 = "";
    var p = document.getElementsByTagName('script')[0],
        s = document.createElement('script');
    s.async = 1;
    s.src = '/botdefense'; // custom endpoint
    p.parentNode.insertBefore(s,p);
}());

Disable HUMAN Apache Module by Envvar

There is a way to disable HUMAN Apache Module using Envvar: set px_skip_mod_by_envvar configuration parameter to On and then, if the environment variable HUMAN_SKIP_MODULE is set, HUMAN Module won't be executed for that request.

<VirtualHost *:80>
    ...
    px_skip_mod_by_envvar On
    ...
</VirtualHost>

Active Header Name

Allows you to pass a specific header (e.g. x-px-active) when px_enabled is off. When the header has a value of 1, the module is enabled for the specific request. When the header has a value of 0, the module is not enabled.

This feature can be used for a/b testing.

Default: Empty

<VirtualHost *:80>
    ...
    px_active_header_name "x-px-active"
    ...
</VirtualHost>

🚧PII (Personally Identifiable Information) Anonymization

Module Enabled

Monitor Mode/Block Mode

Blocking Score

Debug Mode

Sensitive Routes

Allowlist Routes

Enabled Routes

Sensitive Headers

IP Headers

Enrich Custom Parameters

Score Header

API Timeout

Allowed Cookies

Advanced Blocking Response Flag

CSS Ref

JS Ref

Custom Logo

Test Block Flow on Monitoring Mode

Filter By Extension

Filter By HTTP Method

Custom First Party Sensor Endpoint

Disable HUMAN Apache Module by Envvar

Active Header Name

🚧
PII (Personally Identifiable Information) Anonymization