DataDome detection: 1 header turned a block into a login

DataDome's captcha page tells you that something about your connection looks wrong, and the usual reaction is a new proxy. On PayPal in August 2026 a new proxy would have changed nothing. We opened PayPal's public login page four times from fresh profiles on one machine and one connection, changed one request header between runs, and DataDome switched between its captcha page and the login page with that header alone. No account was created and no form was sent.

What is DataDome?

DataDome is a bot protection service that decides for every request to a protected site whether it reaches the site at all. The site installs a server module that forwards each request to DataDome's Protection API and enforces the answer: status 200 passes the request to the backend, any other status goes straight back to the visitor as DataDome's own page. The request body of that API had 76 fields when we read it on 27 September 2026, and the header fields among them are what DataDome can judge before a single line of the page's JavaScript runs.

The same body also carries fields for the method and tool name of an MCP request. What DataDome answers with is set per site: the responses documentation describes its response types, among them Captcha, Block and Device Check, where "the traffic to which the rule applies is redirected to an interstitial page" that checks the browser without a challenge.

What did DataDome react to on PayPal?

DataDome reacted to the Accept-Language header: in 4 of 4 runs on 12 August 2026, one value got the captcha page and the other the PayPal login page. Each run started a fresh profile on the same machine and the same connection, and only the browser's language setting changed. The order A, B, B, A puts each variant at both ends of the series, so a site that changed its mind over the session would have split the result.

Both variants gave the same result in both of their runs, so the spread was zero. The second row went through DataDome's Device Check first and then reached the login page, which is the path the responses documentation describes for that interstitial. Real Chrome on the same connection got the login page as well.

The first header is not an unusual value but an impossible one. The tag de appears twice, and its second copy carries two quality weights, a form Chrome does not produce from its own language settings. The defect was ours: our engine assembled the header in a way Chrome never does. It was fixed on 12 August 2026, the day of the measurement, and every locale we ship has been checked against the derived header since.

Why does the block page blame the IP?

The block page blames the IP because its reason text is a short generic message, not a diagnosis of the request in front of it. In our four runs the IP address was identical for both headers, so the address cannot be what separated the captcha page from the login page. Like most bot detection, DataDome combines several layers into one verdict per request, and its server receives 76 fields for each one; the page a visitor sees names none of them. The signals that give a proxy exit away are covered in Proxy detection.

Two habits follow from this case. Change one thing at a time and keep a control, which here was real Chrome on the same connection, because the reason text will point at the wrong thing. And read the headers as they leave the machine: the HeadersList field keeps their order, while the Chrome DevTools Protocol hands back headers as an object after the request is sent and cannot show that order at all.

A header like this is also invisible to fingerprint test pages that only run JavaScript, because the header itself never reaches the page's script. Only a server that reads the raw request sees it, and DataDome is such a server. The Referer header and Sec-Fetch-Site, another pair a server reads, are covered in Referer header and Sec-Fetch-Site.

How do timezone and locale have to agree with the exit?

Timezone and locale have to fit the exit address, because the server compares the address and the language header while the page's script reads the clock. In our detector audit on 4 July 2026, real Chrome 149 on Windows with a clock that did not match its exit got "Masking detected" on Pixelscan and a 10 percent deduction on BrowserScan. That is the same class of fault as the header above: two values that cannot both be true.

The fix is to treat timezone and locale spoofing as one unit rather than four settings. Scalebrowser writes the timezone, navigator.language, the languages list and the Accept-Language header together from the exit country, for the 62 countries its locale table covers as of September 2026, and leaves a profile unchanged when the exit is outside that table instead of rewriting half of it. The coherence page explains what happens when the exit country cannot be determined.