How to Build an Anti-Bot Challenge the Right Way

Consider a real, working example: a custom Proof-of-Work (PoW) system gating a registration flow. On paper it looks solid — three endpoints and a heavily obfuscated Web Worker:

• GET /api/pow/worker — returns a 178 KB obfuscated JavaScript Web Worker.
• GET /api/pow/challenge — returns a base64 challenge blob, fetched by the worker internally.
• POST /api/pow/verify — accepts {challengeId, solution} and returns {"success":true}.

The worker talks to the page over a typed postMessage protocol: the page sends {t:"start", o: origin}, the worker asks for browser fingerprints (canvas frames, DOM text-measurement rects, WebGL info, performance values, a navigator string), and returns a 12-byte solution. The obfuscation is real — a Function() wrapper, randomised identifiers, a rotated lookup table, control-flow flattening.

It fell to a script with no browser at all. Download the worker, run it under Node.js with eval(), mock self, postMessage, onmessage and fetch, and feed it fake-but-correctly-shaped fingerprint data. The worker fetched the challenge through the mocked fetch, computed the solution, and the script POSTed it back over an HTTP client with a Chrome TLS fingerprint — end to end in under a second. The obfuscation was irrelevant; the design had nothing underneath it. Every principle below comes from why that worked.

The fatal flaw: the verify endpoint only checked {challengeId, solution}. The fingerprint data the worker so carefully collected was never sent to the server and never validated, so the solver sent solid-colour rectangles instead of real canvas renders, a hardcoded GPU string, and static screen dimensions. The server could not object to data it never saw.

If a signal does not reach the server and influence the decision, it does not exist. Make the fingerprint part of the proof:

solution = solve(challenge, sha256(canvasFrames + domRects + webglInfo + perfValues + browserMeta))

The server stores the expected fingerprint hash when it issues the challenge and recomputes it on verify, so fake inputs produce an invalid solution. Then cross-validate components against each other: if the metadata claims an NVIDIA GPU, the WebGL renderer must be NVIDIA; if it reports 4 cores, the solve time should look like 4-core performance. This relates directly to fingerprint clustering — contradictions between fields are free bot signals.

The example solution was a standalone {challengeId, solution} pair, tied to nothing — no session, no IP, no TLS fingerprint, no expiry. The script even fetched the challenge and submitted the verify from completely different contexts. That makes three attacks trivial: pre-compute and replay, run a solve farm that hands solutions to many clients, and submit today’s solution tomorrow.

• Issue the challenge against a session cookie set on page load; require that same session for /challenge, /verify and the protected action.
• HMAC over (challengeId, sessionId, IP, timestamp) and validate all four on verify.
• Expire challenges in 30–60 seconds and rate-limit issuance per IP/session.
• Require the JA3/JA4 TLS fingerprint of the challenge request to match the verify request.

A solution should prove that this client, on this connection, right now did the work — not be a portable token anyone can carry.

The worker had no way to know it was running inside a real browser Worker. Under Node.js eval() it had full global, require, process and module access, and the attacker simply overrode fetch. Obfuscation slowed reading the code; it did nothing to stop running it. Probe the environment from inside the obfuscated worker and feed the result into the computation (don’t just throw — a thrown error is easy to patch out):

// Present in real Workers, absent or different under Node.js eval
if (typeof WorkerGlobalScope === 'undefined') corrupt();
if (typeof importScripts !== 'function') corrupt();
if (typeof process !== 'undefined') corrupt();
if (typeof require !== 'undefined') corrupt();

Then make Worker-only APIs load-bearing parts of the math (crypto.subtle.digest(), high-resolution performance.now(), SharedArrayBuffer/Atomics) so emulation is not optional. Finally, make the code dynamic: embed a per-session nonce at serve time and regenerate variable names and control flow per request, so cached eval()-based solvers break the moment the script changes shape.

Every fingerprint input in the example was forgeable with arithmetic. The canvas was a pure formula, so the solver generated identical bytes with no Canvas API. DOM rects measured a fixed string in a fixed font — constant metrics. WebGL info was just a string. To force real hardware into the loop, lean on things that vary by physical device and feed a hash, never raw values, to the server:

• Seed canvas rendering with a per-challenge random value the server knows; use globalCompositeOperation, shadowBlur and system fonts to amplify GPU anti-aliasing variance, and validate the output hash against known-good GPU families.
• Prefer WebGL shader output — hardware floating-point precision is hard to fake without the actual GPU.
• Randomise font family and size per challenge and use proportional fonts so widths can’t be precomputed.
• Chain frames: frame N’s input depends on frame N-1’s output hash, so the work can’t be parallelised or shortcut.

A good challenge does not just collect a fingerprint — it forces one that has to land inside a real cluster.

The example’s automation checks (navigator.webdriver, a User-Agent blocklist for selenium/puppeteer/playwright) lived in the readable page chunk, not the worker, so the solver never executed them. Two fixes matter:

1. Move detection into the obfuscated worker and make its result feed the computation, so it can’t be skipped by running the worker in isolation.
2. Use behavioural timing: a real browser takes 5–50 ms to render canvas, read DOM rects and query WebGL; the solver responded in under 1 ms. Reject impossibly fast responses, require performance.now() before and after the PoW, and add a server-side fence — too fast (< 200 ms after issuance) is a bot, too slow (> 60 s) is a replay.

Individually, each signal is spoofable; combined with cross-checks they get expensive:

• The User-Agent inside the fingerprint must match the User-Agent HTTP header on verify, and sec-ch-ua-platform must match the reported platform.
• Timezone must be plausible for the client IP’s geolocation.
• If the same session reports different screen sizes or languages across requests, flag it.
• Mix in genuine per-request entropy (crypto.getRandomValues(), collection-time Date.now()) so no two submissions are byte-identical.

The robust version combines the principles into one flow:

1. Issue returns a signed (challengeId, seed, timestamp, sessionId) bundle, bound to a session cookie.
2. The worker uses the seed to drive non-deterministic canvas/WebGL/font operations and probes its environment.
3. The worker hashes all fingerprint data and mixes that hash into the PoW computation.
4. The solution is (challengeId, solution, fingerprintHash).
5. Verify checks the challenge is valid and unexpired, the session matches, the fingerprint hash is consistent with known-good hardware, the solve time fits the reported concurrency, the IP and TLS fingerprint match issuance, and the solution is correct for challenge + fingerprintHash.

If you are building one today, this is the order that buys the most security per unit of effort:

A well-built anti-bot challenge has a few non-negotiable properties: every signal it collects influences a server-side decision; the proof is bound to one client, connection and short time window; the challenge code assumes a hostile runtime and makes non-browser execution expensive; and the work depends on physical-device behaviour rather than reproducible arithmetic. Obfuscation is the last and least important layer — it buys time, not security.

The custom PoW in the example was not beaten by clever cryptanalysis. It was beaten because it trusted the client, validated almost nothing, ran in an environment the attacker controlled, and built its proof out of forgeable arithmetic. Fix those four things and you have a challenge worth the bytes it ships. To see how production vendors implement these ideas at scale, see Cloudflare Bot Management and anti-bot detection.