# Browser challenge

> The proof-of-work page that the edge shows instead of a block when a rule's action is challenge; real browsers solve it automatically in milliseconds.

Some rules can **challenge** a request instead of blocking it: [rate limiting rules](https://developers.openwaf.dev/waf/rate-limiting/#per-path-rules) with `action: challenge` and the [AI Crawl Control policy](https://developers.openwaf.dev/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:

1. The page answers `503` with `Cache-Control: no-store`, so it is never cached or indexed.
2. A small script, with no external resources, computes a SHA-256 proof of work in the browser (usually tens to hundreds of milliseconds).
3. It posts the result to `/__waf/verify`. If it is valid, the edge sets the `__waf_pass` cookie (`HttpOnly`, `Secure`, `SameSite=Lax`) and the page reloads.
4. 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](https://developers.openwaf.dev/ai-crawl-control/verification/).