Configuration Options

Module Enabled

Enables/disables the Enforcer.

Default: True

config = {
 ...
 px_module_enabled: True
 ...
}

config = {
 ...
 module_enabled: True
 ...
}

Module Mode

This feature sets the working mode of the Enforcer.

Monitor mode - Use this mode to fine-tune and test your system. When in the Monitor mode, the Enforcer will pass through requests that would otherwise be blocked based on their score.
Active Blocking mode - Switch to this mode after making sure the Enforcer is operating properly in the Monitor mode. The Enforcer will block requests, if their score is equal to or higher than the set value.

v2.0.0 and up
Name: px_module_mode
Values:

monitor - Monitor mode (default)
active_blocking - Active Blocking mode

v1.2.0 and below
Name: module_mode
Values:

0 - Monitor mode (default)
1 - Active Blocking mode

config = {
 ...
 px_module_mode: 'monitor'
 ...
}

config = {
 ...
 module_mode: 0
 ...
}

Blocking Score

Sets the minimum blocking score of a request.
For best performance, we recommend to keep the blocking score at 100 (default).

v2.0.0 and up
Name: px_blocking_score
Values:
From 0 to 100 (Default)

v1.2.0 and below
Name: blocking_score
Values:
From 0 to 100 (Default)

config = {
 ...
 px_blocking_score: 100
 ...
}

config = {
 ...
 blocking_score: 100
 ...
}

Send Page Activities

Enables sending activities and metrics to HUMAN with each request.
When enabled, populates the HUMAN Portal with important statistics, such as the number of requests blocked and API usage.

Default value: True

config = {
  ...
  px_send_page_activities: True
  ...
}

config = {
  ...
  send_page_activities: True
  ...
}

Logger Severity

Sets the Logger Severity mode of the Enforcer.
v2.0.0 and up
Name: px_logger_severity
Values:

error (default) - The Enforcer logs only errors and fatal events (e.g., exceptions).
debug - The Enforcer logs all debugging events.

v1.2.0 and below
Name: debug_mode
Values:

False (default) - The Enforcer logs only errors and fatal events (e.g., exceptions).
True - The Enforcer logs all debugging events.

config = {
 ...
 px_logger_severity: 'error'
 ...
};

config = {
 ...
 debug_mode: False
 ...
};

Sensitive Routes

Some routes may be more prone to bot attacks than others. For example, routes that execute payments or handle personal information. You can configure these routes as sensitive to ensure a more stringent protection. The Enforcer will make Risk API calls on such sensitive routes, even if the request contains a valid, unexpired cookie.

Default: Empty

Example:

config = {
 ...
 px_sensitive_routes: ['/login', '/user/checkout']
 ...
};

config = {
 ...
 sensitive_routes: ['/login', '/user/checkout']
 ...
};

Sensitive Routes Regex

Some routes may be more prone to bot attacks than others. For example, routes that execute payments or handle personal information. By using regular expressions, you can configure these routes as sensitive to ensure more stringent protection. The Enforcer will make Risk API calls on such sensitive routes, even if the request contains a valid cookie.

Default: Empty

Example:

config = {
...
px_sensitive_routes_regex: [r'^/login$', r'^/user']
...
}

config = {
...
sensitive_routes_regex: [r'^/login$', r'^/user']
...
}

Filter By Routes

You may want certain routes to be accessible regardless of HUMAN's detection (filtered routes). Such allowed routes will not be blocked, regardless of the score they receive. A client request to a filtered route will not generate any risk or async activities.

Default: Empty

Example

v2.0.0 and up

config = {
  ...
  px_filter_by_route: ['/about-us', '/careers']
  ...
}

v1.2.0 and below

config = {
  ...
  whitelist_routes: ['/about-us', '/careers']
  ...
}

Filter by Route Regex

You can use regular expressions to define routes that will be accessible regardless of HUMAN's detection (filtered routes). Such filtered routes will not be blocked, regardless of the score they receive. A client request to a filtered route will not generate any risk or async activities.

Default: Empty

Example

config = {
...
px_filter_by_route_regex: [r'^/about']
...
}

config = {
  ...
  whitelist_routes_regex: [r'^/about']
  ...
}

Enforced Specific Routes

You may want certain requests to be enforced by HUMAN, even when the Enforcer is in the Monitor mode. Requests for predefined route prefixes will go through the full enforcement workflow, and may be blocked based on their score.

Default: Empty

Example

config = {
  ...
  px_enforced_routes: ['/profile']
  ...
};

config = {
  ...
  enforcedSpecificRoutes: ['/home',/^\/$/]
  ...
};

Enforce Specific Routes Regex

You may want certain requests to be enforced by HUMAN, even when the Enforcer is in the Monitor mode. Requests for predefined regular expressions will go through the full enforcement workflow, and may be blocked based on their score.

Default: Empty

Example

config = {
  ...
  px_enforced_routes_regex: [r'^/profile$']
  ...
}

config = {
  ...
  enforced_specific_routes_regex: [r'^/profile$']
  ...
}

First Party Enabled

To prevent suspicious or unwanted behavior on the client side, some browsers or extensions (such as an Adblock extension) may deny the frontend JavaScript code from making requests to other domains. This prevents the HUMAN Sensor from making requests to the HUMAN servers, which greatly limits HUMAN's detection capabilities. To avoid this problem, the First Party feature enables the Enforcer to be used as a proxy for HUMAN servers, and to serve content to the browser from a first party endpoint (i.e., an endpoint on the customer’s domain).

Default: Enabled ('True')
We recommend to keep the First Party feature enabled at all times.

config = {
  ...
  px_first_party_enabled: True
  ...
}

config = {
  ...
  first_party: True
  ...
}

Monitor Specific Routes

When in the Active Blocking mode, use this feature to define trusted routes to be monitored only. Such routes will be treated, as if the Enforcer were in the Monitor mode.

For example, you can put newly introduced routes in the Monitor mode to fine-tune them, while continuing to actively protect the rest of your assets.

For more on the difference between the modes, see Module Mode.

Default: Empty

Example

config = {
  ...
  px_monitored_routes: ['/profile']
  ...
}

config = {
  ...
  monitored_specific_routes: ['/profile']
  ...
}

Monitor Specific Routes Regex

When in the Active Blocking mode, use this feature to define regular expressions of trusted routes to be monitored only. Such routes will be treated, as if the Enforcer were in the Monitor mode.

For example, you can put newly introduced routes in the Monitor mode to fine-tune them, while continuing to actively protect the rest of your assets.

For more on the difference between the modes, see Module Mode.

Default: Empty

Example

config = {
  ...
  px_monitored_routes_regex: [r'^/profile/me$']
  ...
}

config = {
  ...
  monitored_specific_routes_regex: [r'^/profile/me$']
  ...
}

Sensitive Headers

Some request headers (like cookies) may contain sensitive customer information that you don't want to share with either HUMAN or third parties. This feature allows you to define such headers. Once a header is added to the Sensitive Headers list, the Enforcer will exclude it from all its activities (Risk API, async activities) and will not send it to any third party IP.

Default: Empty

Example

config = {
  ...
  px_sensitive_headers: ['cookie', 'cookies', 'x-sensitive-header']
  ...
}

config = {
  ...
  sensitive_headers: ['cookie', 'cookies', 'x-sensitive-header']
  ...
}

IP Headers

Use this feature to define header names that contain the true client IP. For example, this might be required when there are proxies between the Enforcer and the client. Knowing the IP from which the request was received greatly improves detection reliability.

Default: Empty

Example

config = {
  ...
  px_ip_headers: ['x-user-real-ip']
  ...
}

config = {
  ...
  ip_headers: ['x-user-real-ip']
  ...
}

Test Block Flow on Monitoring Mode

While the Enforcer is in the Monitor mode, this feature allows to test the Enforcer’s blocking flow. The feature is activated per request.

TO enable the feature:

Specify the header name (x-px-block in the example below).
Set the header value to 1.

The Enforcer will block the request by bypassing the Monitor mode.

TO disable the feature and stay in the Monitor Mode:

Set the header value to 0.

Default: Empty

config = {
  ...
  px_bypass_monitor_header: 'x-px-block',
  ...
}

config = {
  ...
  bypass_monitor_header: 'x-px-block',
  ...
}