How DataDome detection works, from its own documentation

You load a page and get a 403 with a challenge where the content should be, or the page flashes a short "verifying your device" screen and then carries on. Both are DataDome. Its documentation is specific about what each piece does, so this post works from that: a module on the site's infrastructure, a JavaScript tag in the page, and a cookie that connects them.

The server-side module asks about every request

The site installs a DataDome module in its CDN, load balancer or application server. For each incoming request the module calls DataDome's validate-request API before the site's own code runs. DataDome's API reference lists what gets sent:

• the client IP address
• request headers such as User-Agent, Accept and Referer
• CookiesList, the cookie names in their original order, and CookiesLen
• a client ID taken from the datadome cookie
• optionally, the TLS JA3 and JA4 fingerprints, which DataDome recommends but does not require

A 200 means forward the request to the origin. Anything else means the module returns DataDome's own response, status code and body, straight to you, and the site's server never sees the request. That response is the challenge page.

Two details in that list are easy to miss. The order of cookie names is a property of the client software, not of the person using it, so a scripted client that assembles its own cookie header can be told apart from a browser that sent the same cookies. And the request is judged before any JavaScript runs on it, so a challenge on the very first page load is a decision made from network, headers and TLS alone.

The reference also requires integrations to fail open: if DataDome's answer is missing because of a timeout or an error, the request is let through. It protects real users during an outage.

The JS tag watches the page

The second part runs in your browser. DataDome's JS tag documentation says it collects:

• behaviour, such as mouse movements and keystrokes
• environment details including OS, browser and GPU
• consistency checks on built-in functions and attributes, which DataDome says help detect headless Chrome, Puppeteer and Selenium

The same page says the tag avoids collecting information that may be invasive of privacy, and names canvas fingerprinting as an example of a technique it does not use. If you are fixing a DataDome problem by changing canvas output, the vendor says that is not what its tag reads.

The consistency checks matter most for automation. A stealth plugin works by replacing built-in browser functions with JavaScript versions. Checking whether built-in functions still look and behave like built-ins is exactly the kind of test that catches a replacement. A browser whose values come from the engine has nothing replaced to find, though it still has to be consistent with itself.

The tag also wraps XMLHttpRequest and fetch so that when a background request is blocked, the challenge can be shown instead of a silent failure.

The cookie and Device Check

DataDome's cookie page describes the datadome cookie as "used for both server-side and client-side detection to assess the legitimacy of a request". It is encrypted, holds no personally identifiable information, and lasts one year. DataDome warns site owners not to change its Domain or Path or add HttpOnly, because the tag and the challenge pages need to read and write it.

Device Check is the screen that appears and goes away. DataDome describes it as a verification "that runs on the end user's device, without the need for any user interaction", meant "to spot any type of automation frameworks, spoofed environments or programmatic access to the interfaces". It fires when a request looks suspicious and the resource is sensitive, or when DataDome suspects a bot without enough evidence to block. It has an invisible mode, and DataDome can fall back to a CAPTCHA if it still cannot decide.

What a multi-account user should expect

• One cookie per identity. A one-year cookie that the server reads on every request is an identifier. Shared across accounts, it links them.
• The exit address is judged first. It is in every API call, before your page exists. Our August detection report measured how much the exit address mattered on a DataDome-protected site, and it is the first thing to rule out. See residential vs datacenter proxies for what changes between proxy types.
• A first visit is the weakest case. A profile with no datadome cookie and no history has nothing on record yet.

Where we are the wrong choice

If DataDome blocks you on the first request from every browser you try, the cause is the address or the request itself, and a different browser will not change it. If you collect public data at volume, that is what DataDome is there to stop, and an antidetect browser is not a scraping tool. AntiBrow gives each identity its own local profile, with its own cookie jar and an engine-level fingerprint, and unlimited local profiles are free. That covers per-identity state and consistency. It does not cover address reputation or behaviour.

Check it yourself

In DevTools, look for a datadome cookie on the site and a request to DataDome's tag. Then compare a cold profile and a profile you have used for a week, through the same exit, and note which one sees Device Check.

Sources, fetched 2026-10-22: validate-request API, JavaScript tag, cookies and stored data, Device Check.