# Check my browser

> A public page that tells a visitor why OpenWAF Verify keeps checking their browser, what to fix, and gives a check ID for support.

[Check my browser](https://verify.openwaf.dev/) (in Spanish at [verify.openwaf.dev/es/](https://verify.openwaf.dev/es/)) is a public OpenWAF page for visitors who can't get past the [browser challenge](https://developers.openwaf.dev/waf/browser-challenge/), [under attack mode](https://developers.openwaf.dev/waf/under-attack/) or the [Verify widget](https://developers.openwaf.dev/waf/verify-widget/). In a few seconds it runs the checks that OpenWAF Verify needs in their browser, says what each problem means and what to do about it, runs the real widget and shows a **check ID** they can send to support.

The page is static and sits behind the OpenWAF edge, like your site. It loads nothing from third parties and changes nothing on the device.

## Where visitors come from

When a check fails, the challenge page and the widget link to the page:

- The challenge page shows «Trouble? Check your browser» below its failure message.
- The widget, in its error state, shows «Trouble?» next to «Try again». Its accessible name is the full «Trouble? Check your browser».

Both open in a new tab, in the language of the challenge, with the host the visitor was on and the challenge's support ID:

```text
https://verify.openwaf.dev/?host=example.com&id=3f9c2a7b1e604d85
```

`id` is the challenge's support ID, 16 hexadecimal characters, the same one the [under attack page](https://developers.openwaf.dev/waf/under-attack/#interactive-step) shows in its footer. The widget gets it from the edge with each challenge (`id` in the answers of `/start` and of the interactive step of `/solve`). The page also works without parameters: you can send visitors the link yourself.

The challenge page and the widget leave the link out when the zone uses your organization's [white-label brand](https://developers.openwaf.dev/fundamentals/white-label/#brand), because the page says OpenWAF. With a [client brand](https://developers.openwaf.dev/fundamentals/agencies-and-clients/#client-brand) the link stays, as the «Protected by OpenWAF» line does.

## The checks

Each check ends as **OK**, **Problem** or **Not applicable**. A problem comes with a short explanation and what to do. At the top, the page sums up: «No problems found» or how many it found. **Retest** runs everything again with a new check ID.

The page runs the checks against the OpenWAF edge serving `verify.openwaf.dev`. Only the [access check](#site) talks to the site the visitor came from. When that edge can't run its part (the check service isn't available), the checks that depend on it show «Not applicable», never as the visitor's problem.

### JavaScript

OpenWAF Verify runs in JavaScript. If the page can show its results, JavaScript works. With JavaScript off, the page says so instead and asks to turn it on for the site.

### Web Workers

The proof of work normally runs in a Web Worker, in the background. Without Web Workers it still runs, on the page itself, but slower, and the tab can feel stuck for a few seconds. **What to do:** allow Web Workers for the site (a privacy extension or a browser setting may block them), or try another browser.

### OpenWAF Verify files

Whether `widget.js`, `worker.js` and the check service under `/__waf/challenge/v1/` load. When something doesn't, the page names it. It's almost always a content blocker extension, or a company proxy or firewall. **What to do:** allow `/__waf/challenge/` in the blocker, or ask the IT team to allow it.

### Access to the site

Only when the visitor came with `?host=`. The browser asks `https://<host>/__waf/challenge/v1/ping` (see [edge endpoints](#endpoints)):

| Answer | What the page says |
|---|---|
| `204` | OK: the site answers through OpenWAF. |
| `404` | Not applicable: the site answers, but doesn't use OpenWAF Verify right now. |
| No answer | Problem: OpenWAF works from here, so something blocks the way to that site: an extension, a company filter, or the site is down. |

**What to do:** open the site in a private window without extensions, or from another network. If it still fails, contact the site with the check ID.

### Cookies

The edge sets a test cookie and the page checks that it comes back. After the challenge page, the site gives the browser a first-party pass cookie (`__waf_pass`); if cookies are blocked for the site, the challenge starts again on every page. **What to do:** allow cookies for the site, in the browser's site settings or in the blocker's exceptions.

The test cookie belongs to `verify.openwaf.dev`, so a block that applies to one other site only doesn't show here.

### System clock

The difference between the device's clock and the edge's. Five minutes or more is a problem. The pass cookie has an expiry date: with a clock far ahead, the browser can treat it as expired at once, and the challenge repeats. **What to do:** turn on automatic date and time in the system settings.

### Check speed

The page solves the real proof of work of one widget check, in the real worker, and says how long a check takes on this device: fast (under 1 second), normal (under 3), slow (under 8) or very slow. Three seconds or more is a problem. Battery saver, a busy device or a tab in the background make it slower. **What to do:** keep the tab in front, turn off battery saver or plug the device in, and close heavy tabs.

### Automation

Whether the browser reports that it is controlled by automation software (`navigator.webdriver`). Sites then ask for a tick or refuse the check. **What to do:** close the browser and open it normally. Testing tools and some extensions turn this on.

### Your network

The page shows the visitor their own IP address, with two labels the edge sees for it:

- **Data centre network:** yes, no or unknown, from the list of hosting networks that [risk scoring](https://developers.openwaf.dev/waf/verify-risk/#signals) uses. VPNs and proxies are often in data centres, and sites may show more checks to that traffic. **What to do:** turn off the VPN or proxy for the site, or try another connection.
- **Threat list:** yes when the address is on a [threat feed](https://developers.openwaf.dev/waf/threat-feeds/) the edge uses or the edge saw attacks from it recently. On a shared network (office, mobile carrier, VPN) someone else can be the cause. **What to do:** try another network; if it continues, send the check ID to the site's support.

The page never shows which list or any score.

### Privacy tools

Always informational. OpenWAF Verify doesn't fingerprint the device: no canvas, WebGL, audio or fonts. So canvas and WebGL blockers and browser shields don't change the result. Extensions that rewrite browser functions in JavaScript, such as user-agent or time-zone spoofers, can make it ask for the tick box ([browser checks](https://developers.openwaf.dev/waf/verify-risk/#signals)).

### Live check

The page renders a real `managed` widget and reports how it ended: passed without any action, passed after a tick, asks for the tick, failed (with the widget's error code, such as `rate-limited`), or no answer after 30 seconds. With `rate-limited`, waiting a minute and pressing Retest is enough. Other failures usually come from a problem above.

WebAssembly and the Web Crypto API aren't checked: the proof of work doesn't use them. It computes SHA-256 in plain JavaScript.

## Technical details for support

When the checks end, the page shows:

| Field | Content |
|---|---|
| Check ID | `XXXX-XXXX-XXXX`, for example `K7Q2-9F3M-X4PA`. Crockford base32: no I, L, O or U, so it survives being read out or retyped. |
| Time (UTC) | When the checks ended. |
| Your IP address | Shown to the visitor only. |
| Browser | The browser's user agent. |
| Site | The `host` of the link, if any. |
| Challenge ID | The `id` of the link, if any. |
| Live check | How the [live check](#live-check) ended. |

**Copy results** copies a text for support with the network instead of the IP address (the /24 of an IPv4 address, the /64 of an IPv6 one):

```text
OpenWAF Verify — browser check
Check ID: K7Q2-9F3M-X4PA
Time: 2026-10-29T10:15:03Z
Network: 203.0.113.0/24
Browser: Mozilla/5.0 (…)
Site: example.com
Challenge ID: 3f9c2a7b1e604d85
Cookies: Problem — Cookies are blocked for this site.
…
```

The check ID appears once the edge has recorded the check. If the check service isn't available, the page says «not available» instead.

## Data processed

The edge keeps one record per check for **7 days** on the edge node that served it, then deletes it. It holds the check ID, the time, the host that served the check, the `site` and challenge ID of the link, the network (the /24 or /64, **never the full IP address**), the browser family and major version (for example `chromium/156`, not the full user agent), whether the test cookie came back, the two network labels and the results of the checks, each from a fixed list of values. The record goes to the node's log as well.

The IP address is used to look up the network labels and is shown to the visitor; it isn't stored. The test cookie is `HttpOnly`, `Secure` and `SameSite=Lax`, scoped to the check path, and deleted when the check is recorded. There is no fingerprinting: the page reads nothing about the device beyond what it shows the visitor.

The record is only used by OpenWAF support to find out why a check fails. Details: [Data processed by OpenWAF Verify](https://openwaf.dev/legal/verify-data/#check-page) (draft pending legal review).

## Edge endpoints

The edge serves these on proxied hosts, under `/__waf/challenge/v1/`. You don't configure anything, and your Content Security Policy needs no change: the cross-origin request comes from the check page, not from your pages.

| Endpoint | Hosts | What it does |
|---|---|---|
| `GET /__waf/challenge/v1/ping` | Every proxied host | `204` when the host uses OpenWAF Verify, `404` otherwise. `Cache-Control: no-store`, never a cookie. `Access-Control-Allow-Origin` is sent only to `https://verify.openwaf.dev`. |
| `POST /__waf/challenge/v1/check` | Hosts with a [widget](https://developers.openwaf.dev/waf/verify-widget/) | Starts a check: a new check ID, the edge's time, the requester's IP address and network labels, the work of one widget check, and the test cookie. 20 requests per minute per IP. |
| `POST /__waf/challenge/v1/check/report` | Hosts with a widget | Records the results and answers whether the test cookie came back. 20 requests per minute per IP. |

To see what the page sees for your host:

```sh
curl -sI https://example.com/__waf/challenge/v1/ping
```

## Ask support to look up a check

1. Ask the visitor to open the page from the failure link (or send them [verify.openwaf.dev](https://verify.openwaf.dev/)), wait for the summary and send you the **check ID**, or the text from **Copy results**.
2. Write to [support@openwaf.dev](mailto:support@openwaf.dev) with the check ID, your host and the approximate time, within 7 days of the check.
3. Support finds the record and, when the visitor came from a failure link, the edge's log lines of that challenge ID: what the failed attempt ran into.


If support can't find the ID, the page didn't finish (the tab was closed before the summary, or it showed no check ID), or it's older than 7 days: ask the visitor to run it again. The challenge ID from the under attack footer or the link also helps on its own.