Some rules can challenge a request instead of blocking it: rate limiting rules with action: challenge and the AI Crawl Control policy with the challenge action.
What the visitor sees
A browser navigation (a GET whose Accept includes text/html) gets a short interstitial page:
- The page answers
503withCache-Control: no-store, so it is never cached or indexed. - A small script, with no external resources, computes a SHA-256 proof of work in the browser (usually tens to hundreds of milliseconds).
- It posts the result to
/__waf/verify. If it is valid, the edge sets the__waf_passcookie (HttpOnly,Secure,SameSite=Lax) and the page reloads. - While the pass is valid, the same rule lets the visitor through.
The pass is signed by the edge and tied to the visitor's network; after it expires, or on another network, the visitor may solve the challenge again.
Requests that aren't navigations
Scripts, API calls and form posts can't run the interstitial, so they don't get it:
| Source of the challenge | Non-navigation answer |
|---|---|
| Rate limiting rule | 429 with Retry-After, exactly as block. |
| AI Crawl Control | 403 with {"error":"verificacion de navegador requerida"}. |
Crawlers
A User-Agent alone proves nothing. With AI Crawl Control on, only crawlers verified by IP range, reverse DNS or Web Bot Auth skip the challenge when spoofed_challenge is enforce. See Bot verification.