Check my browserNew

Check my browser (external link) (in Spanish at verify.openwaf.dev/es/ (external link)) is a public OpenWAF page for visitors who can't get past the browser challenge, under attack mode or the 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:

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 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, because the page says OpenWAF. With a 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 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):

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 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 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).

#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:

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):

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 (external link) (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.

To see what the page sees for your host:

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

#Ask support to look up a check

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.