Which JavaScript Properties Are Most Reliable for Bot Detection?

The most reliable JavaScript properties for bot detection are navigator.webdriver, window.chrome, and overridden prototype methods that reveal automation tooling. None of them is a verdict on its own. A single anomaly — even navigator.webdriver === true — is not enough to label a visit as a bot. The properties work only when you combine them and check the rest of the browsing context.

Think of these properties as first-pass filters. They are cheap to read, need no user interaction, and catch the oldest, least sophisticated automation scripts. The catch: modern bots patch or hide these APIs, and privacy tools, travel, corporate networks, and unusual devices can make a genuine human look suspicious. The useful goal is not to find one magic property; it is to build a set of consistent, cross-checked signals.

Why JavaScript properties matter — and why one check is never enough

A browser exposes a predictable set of APIs. Real users work with those APIs as designed. Automation tools — Puppeteer, Selenium, Playwright — must either use the same APIs or fake them. Every fake leaves a trace, but the trace is small.

The Console Debug Evaluator used by BotRefund is one of 106 independent checks BotRefund runs on a visit. The check looks for a mismatch that a real browsing session does not normally create: automation tools often patch or hide browser APIs, but those changes can break when the browser is checked from another angle.

Why not trust a single property? Because a user on a corporate VPN, a frequent traveler, or someone with aggressive privacy extensions can trigger the same kind of mismatch without running any automation. The source material is explicit: a single anomaly is not a bot verdict.

The four properties worth checking first

1. navigator.webdriver

This property returns true when the page is controlled by WebDriver, the protocol behind Selenium and many Puppeteer setups. It is the most direct signal available and the first thing a script should read.

Reliability: high for naive scripts, low for evasion tools. Most modern automation frameworks now add a command-line flag to spoof navigator.webdriver to false. A false value proves little; a true value proves a lot.

2. window.chrome

Real Chrome builds expose a chrome object on the window. Headless browsers and older automation builds often omit it or expose only part of it. Checking window.chrome and probing its sub-objects (like chrome.runtime or chrome.csi) catches browsers that were started in a stripped-down mode.

Reliability: medium and declining. Newer Chrome versions expose window.chrome even in headless mode, so this check must be paired with something else.

3. Overridden prototype methods

Automation tools often patch methods like navigator.permissions.query, HTMLCanvasElement.prototype.toDataURL, or Function.prototype.toString to hide themselves. Reconstructing the original method and comparing the two reveals the patch. This is called prototype manipulation detection.

Reliability: high against patched builds, low against cleanly compiled automation that never touches prototypes. It is the most complex of the three to implement correctly.

4. Plugin and MIME type inventory

Real browsers list plugins and MIME types. Headless instances often report an empty or unnaturally sparse list. Reading navigator.plugins length and comparing it against what the same browser engine normally exposes can flag a stripped-down automation build.

Reliability: useful as a corroborating signal, weak as a standalone test. Many legitimate setups — enterprise builds, kiosks — also ship minimal plugin lists.

How evasion tools fight back

The arms race matters because it changes how you structure your checks. The affiliate lead fraud material describes the techniques plainly: headless browsers using Puppeteer, Selenium, or Playwright load the site, navigate to form inputs, and fill them in automatically; human-in-the-loop CAPTCHA solving centers route forms through cheap solving services; spoofed data pools inject real-looking names and email domains; residential proxy routing spreads submissions across consumer-owned IP addresses.

The implications for JavaScript properties:

• Command-line flags can suppress navigator.webdriver before the page loads.
• Init scripts can redefine window.chrome and related objects before your code runs.
• Stubbed APIs can make plugin and MIME lists look normal.
• Behavioral emulation (simulated mouse movement, hover, scroll) makes the session look human even when the property checks are neutral.

That last point is why property checks alone are insufficient. A bot that passes all four property checks will still fail a behavioral audit: it lacks natural pointer tremor, it types faster than a human can, and it never scrolls. The source material describes exactly this — superhuman input speeds under 1ms, robotic linear mouse movements, and absence of humanlike mouse tremor are all separate behavior signals.

Decision framework: which signals to combine

Treat each JavaScript property as a piece of evidence, not a verdict. The decision rule is simple:

1. Read all four property signals on every page load and on every click.
2. If navigator.webdriver is true, treat the visit as high-risk and run a deeper behavioral audit before allowing any action.
3. If window.chrome is missing or malformed in a Chrome-claiming browser, flag it as medium-risk and cross-check device and network signals.
4. If prototype manipulation is detected, log it as evidence of evasion and combine it with pointer and speed checks.
5. If all four properties look clean but the behavioral signals (no scroll, sub-millisecond input, no mouse tremor) point to automation, trust the behavior over the properties.

Comparison table

Ease of spoofing and risk ratings are general technical observations, not vendor guarantees. Test against your own user base before relying on any single row.

Key facts

Limitations — when these checks fail

This is the section most bot-detection guides skip. Any JavaScript property check can be defeated by a determined attacker, and worse, any of them can flag a legitimate user.

Consider the scenarios the source material explicitly calls out:

• A privacy-focused user with strict extensions may have a normal prototype but a reduced plugin list.
• A user behind a corporate VPN may have a different navigator object shape than a home user.
• A traveler on a hotel network, or someone with a rare device, can trigger multiple anomalies at once.

That is why the guidance is emphatic: a single anomaly is not a bot verdict. The correct engineering pattern is to record each property as an objective fact about the visit, then cross-check it against browser, network, device, and behavior data. If the evidence aligns, you have a case. If it does not, you risk blocking a paying customer.

There is also a practical limit to how far client-side JavaScript can go. Once the page is loaded, the properties are already fixed; a bot that compiles its own browser build can make any property look clean. The only defenses that survive this are the ones that measure how the browser behaves over time — pointer path, click rhythm, scroll depth, session length — because those are not exposed as simple property reads.

FAQ

Is navigator.webdriver always true for bots?

No. Headless browsers launched without special flags expose navigator.webdriver as true. But most modern automation setups add a flag to force it to false, so a false value does not clear a bot. A true value is stronger evidence, but it still needs corroboration.

Can a real user ever have navigator.webdriver set to true?

In practice, almost never. It is a strong signal. But the cost of a false positive is high enough that you should still pair it with at least one independent check before blocking a session.

What is prototype manipulation detection?

It compares an overridden method (for example, navigator.permissions.query) against the original browser implementation. If the method has been replaced to hide automation, the comparison fails. The technique is powerful but requires more code to maintain.

Which property should I check first?

Start with navigator.webdriver because it is one line and gives a strong signal for naive scripts. Then add window.chrome and a prototype check for anything that reaches a form or checkout.

Do I need to build this detection myself?

You can, but a reliable implementation combines dozens of checks plus behavioral analysis. BotRefund, for example, runs 106 independent checks and a prediction model. If you build your own, expect to spend real time tuning against false positives.

The final decision rule

When you see navigator.webdriver === true, or a missing window.chrome on a Chrome browser, or a patched toDataURL, do not block the user. Instead, flag the visit and feed the signal into a broader audit that includes pointer behavior, input speed, scroll depth, and session length. Block only when the corroborated evidence crosses a threshold you define.

That is the only rule that survives contact with real users: use properties as evidence, never as a verdict.