HUMAN Security
Bot management
Also known as: PerimeterX, Bot Defender, px
The former PerimeterX. Blocks with a 403 that often carries an explicit x-px-blocked header, and answers blocked AJAX calls with JSON instead of an HTML challenge page.
HUMAN's Bot Defender, still widely called PerimeterX after the product's original name, deploys as an enforcer at the edge or in the application, paired with a client-side sensor. The enforcer computes a score from 0 to 100 and blocks above a configured threshold, with the default blocking score documented at 100.
The enforcer runs in monitor mode by default. That detail explains a common confusion: a site can have HUMAN fully deployed and still block nothing, because blocking has to be switched on explicitly. Detection and enforcement are separate decisions.
HUMAN's most distinctive feature for API callers is the Advanced Blocking Response. Rather than returning an HTML challenge page to an AJAX request, which would be useless to a fetch or XHR caller, the enforcer returns a JSON object containing everything needed to render the challenge inside the page. So on a HUMAN site, a blocked API call and a blocked page load look completely different on the wire.
How to identify it
- x-px-blocked on the response is a direct block marker and the strongest available signal.
- Cookies beginning _px, most commonly _px3, _pxvid, _pxhd, and pxcts.
- A JSON body with PerimeterX block fields on an AJAX request, rather than HTML.
- Requests to collector endpoints, or a sensor script loaded from a PerimeterX or HUMAN domain.
- A block page referencing a reference ID and, on older deployments, PerimeterX branding.
Headers
- x-px-blocked: Set on block responses by common enforcer deployments. Observed live as x-px-blocked: 1 alongside a 403.
- X-PX-block-page: Enforcer-side header used to inject a custom block page, documented in the Fastly enforcer. Visible to operators rather than to clients.
Cookies
- _px3: The main short-lived risk cookie. HUMAN's cookie documentation gives the _px family, including _px, _px2, and _px3, an expiration of 5.5 minutes, so it is re-minted constantly during a session.
- _pxvid: Visitor identifier, a randomly generated ID with a one-year lifetime, used for browser detection.
- _pxhd: Server-side detection cookie carrying a visitor ID, also one year. This is the returning-visitor credential.
- _pxac: Access token cookie. HUMAN documents that if its value matches the token configured in the console, the request is allowlisted, so it is the sanctioned mechanism for letting known automation through.
- pxcts: Cross-tab session identifier, falling back to local storage when first-party cookies are blocked.
Status codes
403 Enforcer block
Blocked. Observed behaviour.
The enforcer scored the request above the blocking threshold and refused it.
What triggers it
- A risk score at or above the configured blocking score, which defaults to 100.
- An absent or expired _px3 cookie, which is easy to hit given its 5.5 minute lifetime.
- Sensor signals that never arrived, because the client-side script did not run.
- Address reputation, or a fingerprint inconsistent with the claimed browser.
How to confirm it
- x-px-blocked on the response.
- _px family cookies in the exchange.
- A block page carrying a reference ID for support.
What to do about it
- Capture the reference ID from the block page. It is what a site operator needs to find the decision in their console.
- The very short _px3 lifetime means a session that idles for six minutes is effectively a new, unverified session. If your failures correlate with pauses rather than with volume, that is the likely mechanism.
- For sanctioned automation, ask the operator about the _pxac access token. HUMAN documents it as a supported allowlisting path, which is a far better arrangement than trying to look like a browser.
HTTP/2 403 server: CloudFront x-px-blocked: 1 x-cache: LambdaGeneratedResponse from cloudfront content-type: text/html <html><head><title>Access to this page has been denied</title></head>...
403 Advanced Blocking Response on an AJAX call
Challenge. Documented by the vendor.
A blocked fetch or XHR request answered with a JSON object describing the challenge, so the page can render it inline instead of navigating to an interstitial.
What triggers it
- A blocked request whose Accept header indicates JSON rather than HTML.
- Auto ABR, which HUMAN documents as enabled by default when Bot Defender is integrated.
How to confirm it
- A JSON body carrying block and challenge fields where the API's normal payload should be.
- The response arriving on an XHR or fetch call rather than a document navigation.
What to do about it
- Parse defensively. An API client that assumes a 403 has no meaningful body will miss the fact that this one explains itself.
- This is why a HUMAN-protected API and its web pages behave differently under the same block. Test both paths rather than generalising from one.
429 Rate limited
Rate limited. Observed behaviour.
Request rate exceeded, separately from the risk score decision.
What triggers it
- Request volume above a configured threshold for the address or session.
How to confirm it
- _px cookies present, sometimes with retry-after.
What to do about it
- Back off and reduce concurrency. This one clears with time; the score-based 403 does not.
200 Monitor mode
Allowed. Documented by the vendor.
Detection ran and scored the request, but the enforcer is in monitor mode so nothing was blocked. HUMAN documents monitor mode as the default until px_block_enabled is set.
What triggers it
- A new deployment still being tuned.
- A route deliberately kept in monitor mode via the monitored routes configuration.
How to confirm it
- Nothing visible to the client. The score may be passed to the application in an upstream header.
What to do about it
- Worth knowing that a site can be watching without blocking, and can switch enforcement on later without changing anything you can see. Traffic that works today is not proof it is welcome.
If you run a site behind it
- Blocking is opt-in. Leaving the deployment in monitor mode while tuning is the documented default, and it is the right way to size the false positive cost before enforcing.
- Do not change the blocking score without support involvement. HUMAN's own documentation says as much, because the score distribution is model-specific.
- Enable Auto ABR for single-page applications. Returning an HTML challenge page to a fetch call breaks the application rather than challenging the user.
- Use the _pxac access token for partners and known integrations instead of address allowlists, which age badly.
If your traffic is being caught by it
- x-px-blocked is one of the most explicit block markers any vendor emits. If you see it, there is no ambiguity to resolve.
- The 5.5 minute cookie lifetime is the detail that surprises people. Long-lived sessions with idle gaps behave very differently from continuous ones.
- HTML and JSON endpoints on the same site block differently. Do not assume what you learned from one applies to the other.