Skip to main content
Version: Next

Bot protection

Bot protection scores a bounded request fingerprint and applies monitor, challenge, or block when the score reaches the configured threshold. Start in monitor mode so normal automation and browsers establish a baseline before challenges or blocks affect clients.

Configure the decision​

The threshold is a score from 1 through 100. Rules contribute bounded weights; the configuration also sets a clearance TTL, limited to one day. The fingerprint is derived from selected request fields, including method, normalized path, and a small allow-list of headers. It is not a durable user identity.

In challenge mode, a matching request is directed to the challenge flow. A successful challenge creates a clearance for the configured TTL; requests without a valid clearance remain subject to the policy. Challenge responses must not be cached by shared caches or CDNs, or one visitor could receive another visitor's challenge/clearance state. Preserve the challenge endpoint and its cookies when configuring an upstream cache or CDN.

Verify: in a non-production environment, set a low threshold with monitor mode and send a request that matches a test rule. Confirm the score and category are recorded while the request continues. Repeat in challenge mode and verify that the challenge endpoint responds and that a solved clearance changes only the intended subsequent request.

Treat crawler claims as untrusted​

Trusted-crawler records contain both a user-agent predicate and a domain predicate. They are records for future signed ingress verification; a client-provided User-Agent, Host, reverse-DNS-looking value, or forwarded header alone does not prove crawler origin. Do not create an allow path based solely on headers a public client can forge.

Verify: send the same crawler-looking headers from an ordinary client. The request should not gain trusted-crawler status solely from those headers. Review any trusted-crawler integration with its signed ingress metadata before relying on it for bypasses.

Roll back deliberately​

If challenge completion or legitimate automation fails, return to monitor mode first, preserve the collected evidence, and adjust one rule, threshold, or TTL at a time. Do not solve a false-positive incident by broadly disabling unrelated security controls.

Verify: after rollback to monitor mode, the previously affected request should reach its upstream while a monitor event remains available for review.