Dev pages demonstrating the ENCODE WAF CAPTCHA gate

[turner]

Why

ENCODE fronts www.encodeproject.org with an AWS WAF that challenges browser-looking requests, returning 405 Method Not Allowed with x-amzn-waf-action: captcha. The status code is misleading — nothing about the request used the wrong verb — so the failure sends you looking in the wrong place. The practical cost is that no igv.js-based app can load ENCODE tracks during local development, and we can't reproduce user-reported bugs involving ENCODE data on our own machines.

Everything written about this so far has been about a status code and a header. Neither of us had actually seen the CAPTCHA.

What's here

dev/encode/see-the-captcha.html — presents the challenge to a human. The key finding: the WAF challenges a plain top-level navigation, with no Origin header, no localhost, and no igv.js involved. Clicking a link to an ENCODE bigWig renders a live AWS WAF "Human Verification" page with a solvable puzzle widget loaded from captcha.awswaf.com. The page offers three views:

1. A button opening the ENCODE file in a new tab — the challenge, straight up
2. The same challenge rendered inline in an iframe (the response sets no X-Frame-Options and no framing CSP)
3. A button dumping the raw 2119 bytes of challenge HTML that a bigWig reader receives in place of binary data — which is why the reader reports a bad magic number rather than "you were blocked"

dev/encode/encode-captcha-gate.html — the diagnostic view. Raw range-request probes against two gated ENCODE bigWigs plus an ungated control, the same URLs loaded through igv.js so the partial-page failure is visible, and a copy-pasteable curl repro built from the page's own origin.

Measurements against the live host

browser UA, NO Origin (i.e. clicking a link)  → 405 + x-amzn-waf-action: captcha
browser UA, no Origin, + navigation Sec-Fetch → 405
browser UA + localhost Origin (the xhr case)  → 405
plain curl (honest User-Agent)                → 307

One correction to the internal write-up this came from: the challenge response is fully readable from page JavaScript. It carries access-control-allow-origin: * and, notably, access-control-expose-headers: x-amzn-waf-action. This is not a CORS failure, and reporting "this data provider blocked the request" instead of "405" needs no server-side cooperation — the honest signal is already reachable in the browser.

Also

Adds an 'encode' -> 'ENCODE' section label to scripts/buildDevDashboard.cjs and regenerates dev/dev.html.

Testing notes

Use a private/incognito window. Solving a WAF challenge earns an aws-waf-token for the host that waves you through afterward, so a repeat visit may hand you a file download instead of the puzzle. Both pages warn about this.

These are dev pages only — no library code changes.

🤖 Generated with Claude Code