Inside an anti-bot client script: collect, challenge, token

Anti-bot systems such as DataDome, Akamai Bot Manager, Kasada and Cloudflare all run the same loop: a client script collects browser signals, solves a challenge, and posts both to the vendor, which returns a token that unlocks the site. What differs between vendors is what the token is bound to and how long it lasts.

The loop at a glance

sequenceDiagram
    accTitle: The anti-bot loop
    accDescr: On the first visit the browser runs the vendor script and earns a token, later requests present the token for validation, and behavior keeps streaming to the vendor for the rest of the session.
    participant B as Browser
    participant S as Site edge
    participant V as Vendor
    rect rgba(99, 102, 241, 0.12)
    Note right of B: 1. first visit: earn a token
    B->>S: GET /page (no token)
    S-->>B: page + vendor script, or interstitial
    Note over B: collect fingerprint<br/>run challenge (VM / PoW)<br/>sample behavior
    B->>V: POST payload (encoded, 5–50 KB)
    V-->>B: Set-Cookie token (bound to IP, TLS, UA, fingerprint)
    end
    rect rgba(34, 197, 94, 0.12)
    Note right of B: 2. later requests: present it
    B->>S: GET /page (Cookie: token)
    S->>V: validate token (cached at edge)
    V-->>S: ok / re-challenge / block
    S-->>B: content
    end
    rect rgba(245, 158, 11, 0.14)
    loop 3. while the session lives
        B->>V: behavior batches
        V-->>S: updated score, may invalidate token
    end
    end

Every vendor's product is a variation of this diagram. The differences that matter to a scraper are the token's bindings and its lifetime, both decided in the fifth step.

The loop

1. Load. The site includes the vendor script on every page or at the edge. On first request without a valid token, the edge may serve an interstitial page containing only the challenge.
2. Collect. The script gathers the fingerprint signals from the fingerprint anatomy post: navigator properties, rendering hashes, fonts, integrity checks for patched functions, and a short window of behavioral events.
3. Challenge. The script executes a workload the server can verify. Vendors differ: some use a proof-of-work hash search, some execute obfuscated bytecode in a custom interpreter whose correct output depends on the environment, some do both.
4. Submit. Signals plus challenge answer are encrypted or encoded and posted to a vendor endpoint, sometimes proxied through the site's own domain to avoid ad blockers.
5. Token. The response sets a cookie (datadome, _abck for Akamai, reese84 for Imperva, cf_clearance for Cloudflare) or returns header values (Kasada's x-kpsdk-* family). The edge checks the token on subsequent requests and skips the challenge while it remains valid.
6. Re-score. Behavioral data keeps flowing. The token can be invalidated mid-session if the score degrades.

What the token is bound to

A token that worked from any client would be trivially shared, so vendors bind it. Common bindings:

• The IP address or a prefix of it, so a token minted on one exit cannot be used from another.
• The TLS fingerprint, so a token minted by Chrome is rejected when presented by requests.
• The user agent and a hash of the client-side fingerprint.
• A short lifetime, from minutes to a day, with sliding renewal while behavior looks fine.

Which bindings a vendor enforces is the entire question behind replay strategies. If the binding is IP plus TLS, then minting a token in a real browser on a given IP and replaying it from an impersonating HTTP client on the same IP works until expiry. If the binding includes a per-request signature derived from the challenge state, replay fails and the browser has to stay in the loop.

The obfuscation layer

The client script is designed to be hard to read and hard to re-implement outside a browser. Techniques seen in the field: string encryption with runtime decoding, control-flow flattening, dead code, self-checking integrity hashes, and a bytecode virtual machine where the actual logic is data interpreted by a loop. The VM approach is the strongest: the JavaScript you can read is an interpreter, and the program is an opaque array.

Two things changed this picture. First, reversing is no longer artisanal: an LLM with the script in context can deobfuscate, name functions and explain the VM's opcodes in minutes, and agentic tools can do it unattended. Second, the vendors know this, so the trend is to make the script matter less. Behavioral scoring, server-side consistency checks and short token lifetimes do not depend on secrecy.

The vendors' 2026 moves show both halves. DataDome compiled its Device Check and slider challenge logic into bytecode for a custom in-browser interpreter, which raises the cost of replaying the challenge from outside a browser without adding any new network signal. Kasada's VM and integrity checks are reported to be unusually sensitive to which automation-protocol commands a driver sends, which is a detection of the driver rather than the script's secrecy. Akamai split automated traffic into finer classes (training crawlers, search crawlers, fetchers and agents) so that operators set policy per class and inconclusive passive evidence escalates to active device and behavior checks.

The identity layer: Web Bot Auth

The largest change since this series was first drafted is that hiding stopped being the only option. Web Bot Auth, led by Cloudflare and now an IETF draft, applies HTTP Message Signatures (RFC 9421) to bot traffic. An operator generates a key pair, publishes the public key as a JSON Web Key Set at a well-known URL on its own domain, and signs each request; Signature-Input and Signature headers carry the signature and a Signature-Agent header says where the key lives.

The receiving edge fetches the key and verifies. Cloudflare announced it in May 2025 and introduced "signed agents" as a bot class in August 2025, with ChatGPT agent, Block's Goose, Browserbase and Anchor Browser as the first cohort; signed agents appear in its public Radar bots directory beside verified bots, and enterprise customers can write rules against the class. DataDome verifies Web Bot Auth signatures across its platform as one input to its Agent Trust scoring, and AWS WAF is reported to have added support in late 2025.

For scrapers the consequence is simple. A signed request is not anonymous and does not need to pass the fingerprint gauntlet; it passes or fails on policy. An unsigned request from an automated client is, increasingly, assumed to be hiding something. The warm-and-replay economics below still apply to the unsigned path, and the unsigned path is the one getting more expensive.

Economics of warm-and-replay

Minting a token costs a browser session: a few seconds of CPU and memory and one request to the vendor. Replaying it costs one HTTP request. If a token is valid for an hour on an IP and the site allows a few hundred requests in that hour before rate limits, the browser cost amortizes to a fraction of a cent per page.

If the vendor rotates tokens every few requests or binds them to a per-request signature, the browser cost is paid on every page and the approach collapses to "just use a browser". Vendors tune the lifetime and binding knowing exactly this calculation.

Demonstration: watch the loop in DevTools

This demonstration uses no vendor's live protection and does not bypass anything. It observes. Pick any site whose network tab shows a well-known anti-bot script and read the traffic:

1. Open DevTools, Network tab, and load the page. Filter by the vendor's hostname or by Fetch/XHR.
2. Find the first POST to the vendor endpoint. Its body is encoded; note its size (typically a few to tens of kilobytes). That is the fingerprint plus challenge payload.
3. Look at the response headers: a Set-Cookie with one of the names above, with its Max-Age. That is the token and its lifetime.
4. Reload the page. The POST does not repeat, or repeats with a smaller body. The token is in the Cookie header of every request.
5. In Application, delete the cookie, reload, and watch the POST return. Change your IP (switch to a mobile hotspot) without deleting the cookie, reload, and observe whether the POST returns. If it does, the token is IP-bound.
6. In Console, run document.scripts.length and find the vendor script. Pretty-print it. Note the shape: a large array of strings or numbers, a decoding function, and a loop that switches on values. That is the VM.

What you have at the end is a diagram of the loop for that site: which endpoint, how large the payload, what the token is called, how long it lives, and what it is bound to. No code was broken and nothing was bypassed. Everything a scraping strategy needs to decide between "browser throughout", "warm and replay" and "walk away" is in that diagram.

Frequently asked questions

How does DataDome detect bots?

Its script collects fingerprint and behavioral signals on the page and posts them, with a challenge answer, to DataDome, which sets a datadome cookie when the session passes. In 2026 its challenge logic runs as bytecode in a custom interpreter, and its Agent Trust product adds identity checks for AI agents.

What is an anti-bot token?

It is proof that a browser passed the vendor's checks, stored as a cookie such as _abck, datadome, reese84 or cf_clearance, or sent as headers. The site's edge checks it on later requests. It is usually bound to the IP, the TLS fingerprint and the browser fingerprint, and it expires.

Can an anti-bot token be reused by another client?

Only while its bindings hold. If a token is bound to the IP and the TLS fingerprint, a client with the same IP and an identical handshake can present it until it expires. Vendors that sign each request with a value from the challenge make reuse impossible.

What is Web Bot Auth?

Web Bot Auth is an IETF draft, led by Cloudflare, that lets bots and AI agents sign each HTTP request with a published key using HTTP Message Signatures (RFC 9421). Sites can then admit identified agents by policy instead of guessing from fingerprints.