Profile
Back to NewsBack
GitHub Trending 10 min
Reader Mode
rebrowser/rebrowser-bot-detector: Modern tests to detect automated browser behavior. Cover most important leaks from Puppeteer and Playwright.

rebrowser/rebrowser-bot-detector: Modern tests to detect automated browser behavior. Cover most important leaks from Puppeteer and Playwright.

6 hours ago

🕵️ Modern tests to detect automated browser behavior

The goal of this repo is to have actual relevant tests that you could use with your automation software to adequately estimate your chances for success in the modern world of web.

There are many pages by different people containing various tests to detect bots. Some of these pages are 5+ years old and target techniques that are not relevant anymore. Some people think that using puppeteer-extra-plugin-stealth with all the options on is enough, but unfortunately, many of them are not really relevant to the current state of automation and could even hurt your fingerprints and success rate.

This repo contains tests to detect some really basic stuff which is quite easy to implement on any website. It's guaranteed that all these tests are used by major anti-bot companies in their products. Moreover, each of them has their own proprietary algorithms and ideas on how to test your browser for automation. But 90% of the time when you're getting blocked or see any CAPTCHA, it's just because of these tests below.

If you do any kind of browser automation, you might want to make sure that your setup pass these tests. If it doesn't, then you might not achieve any high success rates for your automation.

⚠️ The recommendation is to take care of all of these tests before you try to find high-quality proxies, adjust your automated behavior, and do any other optimizations with your pipeline. These tests are crucial to be passed.

➡️ You can try all the tests on this page: https://bot-detector.rebrowser.net/

These tests mainly focus on Chromium automated by Puppeteer and Playwright but could also be useful for testing other automation tools.

How to pass all the tests?

Just follow the tips on the page. Some require extra settings, some require patching your Puppeteer or Playwright with rebrowser-patches.

What are the tests?

Our goal is to keep this list in an actual state. If you would like to suggest any new tests or any adjustments, please open a new issue. Any feedback will be appreciated.

runtimeEnableLeak

By default, Puppeteer, Playwright, and other automation tools rely on the Runtime.enable CDP method to work with execution contexts. Any website can detect it with just a few lines of code.

With Runtime.enable on, Chrome serializes every console argument to send it over CDP. The classic check (a getter on error.stack that fires during console.debug(error)) stopped working in Chrome 137, but the serialization still runs Error.prepareStackTrace and reads the error's name an extra time, so the test checks those too. Open DevTools trigger it as well, which is a red flag on its own, and so can a logging library or extension that inspects console calls.

You can read more about it in this post: How to fix Runtime.Enable CDP detection of Puppeteer, Playwright and other automation libraries?

Fix: use rebrowser-patches to disable Runtime.enable.

sourceUrlLeak

Puppeteer will automatically add a unique source URL to every script you run through it. It could be detected by analyzing the error stack.

The test also flags a frame from a script that has a bare file name and no URL, such as at app.js:4:14: code injected with a bare //# sourceURL. rebrowser-patches 1.1.0 and older used app.js for Puppeteer. Page code can do the same, so this part is yellow.

Fix: use rebrowser-patches, which adds no source URL at all.

mainWorldExecution

Your target website could alter some really popular functions such as document.querySelector and track every time you use this function for your scripts. It's quite dangerous and will quickly raise a red flag against your browser.

Fix: use rebrowser-patches to run all of your scripts in isolated contexts instead of the main context.

navigatorWebdriver

Good old navigator.webdriver. It's Chrome's way to indicate that this browser is running by automation software.

Fix: just use the --disable-blink-features=AutomationControlled switch when you launch your Chrome.

bypassCsp

Sometimes developers use page.setBypassCSP(true) to be able to run their scripts in some specific edge cases to avoid Content Security Policy (CSP) limitations. This behavior is unacceptable in any real browser as it's a high security risk.

Fix: you need to change your code in a way so you don't need to call this method; basically, avoid breaking CSP.

viewport

When you run Puppeteer, by default, it uses an 800x600 viewport. Playwright uses 1280x720 as default value.

These exact sizes are a hint rather than proof, since an ordinary browser window can end up at them too, so the test marks them yellow. Anti-bot systems still weigh them together with other signals.

Fix: use defaultViewport: null (Puppeteer) and viewport: null (Playwright).

window.dummyFn

The goal is to test that you can access main world objects. If you apply rebrowser-patches, then you cannot easily access the main world as all of your page.evaluate() scripts will be executed in an isolated world. To be able to do that, you need to use some special technique (read How to Access Main Context Objects from Isolated Context in Puppeteer & Playwright or see rebrowser-patches repo for details). This test will help you to debug it.

useragent

Puppeteer and Playwright use Google Chrome for Testing out of the box. It's a red flag for any anti-bot system.

pwInitScripts

Playwright injects __pwInitScripts into the global scope of the every page by default.

exposeFunctionLeak

It's quite popular to use page.exposeFunction() in Puppeteer and Playwright to pass some function from nodejs to browser env. However, this method is full of leaks in both of these libraries. Playwright 1.59 and older, and Patchright, wrap the exposed function in code that a page can read with toString().

headless

Headless Chrome gives itself away in several ways: HeadlessChrome in the user agent or navigator.userAgentData.brands, and, for chrome-headless-shell (Playwright's default headless mode, Puppeteer headless: 'shell'), a missing window.chrome and a Notification.permission that disagrees with navigator.permissions.query(). Softer signals are a desktop with no pointing device, an 800x600 screen and WebGL rendered by SwiftShader (Chrome 138+ has no automatic SwiftShader fallback).

Fix: run Chrome headful (e.g. under Xvfb). If you must run headless, use the new headless mode (--headless=new), not chrome-headless-shell.

platformMismatch

When you override the user agent to look like another OS, navigator.platform and the client hints in navigator.userAgentData usually keep telling the truth. Puppeteer page.setUserAgent(string) also leaves navigator.userAgentData.brands empty, which never happens in a real desktop Chrome (apps that set a custom WebView user agent can cause it on mobile, so it's rated softer there).

The test also checks the CSS system colour ActiveText (idea by heydryft). Since Chrome 138, in the light colour scheme, it resolves to pure red from Chrome's built-in palette on Linux and macOS, while Chrome on Windows uses the system hotlight colour, rgb(0, 102, 204) by default. So a browser that claims Windows but renders light ActiveText red (with forced colours off) is likely running on another OS, even if the user agent, navigator.platform and client hints were all spoofed consistently (e.g. by puppeteer-extra-plugin-stealth). Only a custom Windows colour scheme with a pure red hotlight colour would look the same.

Fix: don't pretend to be another OS. If you override the user agent, pass matching userAgentMetadata and platform too, and run on the OS you claim.

workerConsistency

Values faked with page scripts (evaluateOnNewDocument, addInitScript, stealth plugins) and some CDP overrides (e.g. Playwright locale) don't reach Web Workers. The test compares navigator in a worker with the page. A different user agent, platform or brand list is a strong sign; different languages or CPU core count is a weaker one, because privacy extensions can cause it too.

Fix: avoid faking navigator properties; if you need a different locale, launch the browser with it.

nativeTampering

Stealth plugins replace native functions or wrap them in a Proxy and patch Function.prototype.toString to hide it. A page can still tell: a Proxy doesn't catch a cyclic __proto__, injected wrappers show up in error stacks, and the iframe.contentWindow evasion of puppeteer-extra-plugin-stealth returns the parent window. Fingerprint-spoofing extensions cause the softer signals too.

Fix: don't patch native functions. Fix leaks at the source (launch flags, a real browser, rebrowser-patches) instead of covering them with JavaScript.

mobileEmulation

Mobile emulation in Puppeteer (page.emulate()) and Playwright (devices) only changes what CDP can change. navigator.maxTouchPoints is 1, navigator.platform still reports the desktop CPU, and an iPhone user agent comes with a Chromium engine.

Fix: use a real device for mobile traffic.

documentInterception

Some automation tools serve the page themselves instead of letting the browser load it: they intercept the request through DevTools (Fetch.fulfillRequest, Playwright route.fulfill()) and hand the body back. The browser then records the page with an empty network protocol (nextHopProtocol) even though data was transferred, which never happens on a normal load (h2, h3, http/1.1) or a load from cache. Patchright does this on every page load once it uses addInitScript or exposeFunction, to inject its scripts. The test runs in Chromium-based browsers only.

Fix: don't serve the main document from your automation script.

popupBlocking

The page calls window.open() without a click. A normal browser blocks it, but Puppeteer and Playwright launch Chrome with --disable-popup-blocking, so the popup opens (the page closes it right away). A user who allowed popups for the site gets the same result, so the test is yellow at most.

Fix: use rebrowser-patches, which drops the switch, or pass ignoreDefaultArgs: ['--disable-popup-blocking']. Popups opened by page.click() still work.

ipcFloodingProtection

The page makes 300 quick history.replaceState() calls in a hidden iframe. Chrome ignores the ones after 200 within 10 seconds (Firefox and Safari throw an error instead). Puppeteer and Playwright launch Chrome with --disable-ipc-flooding-protection, so all 300 go through.

Fix: use rebrowser-patches, which drops the switch, or pass ignoreDefaultArgs: ['--disable-ipc-flooding-protection'].

storagePartitioning

The page saves a random value in localStorage and loads a hidden iframe from another site, which in turn loads a frame from the page's own site. Chrome keeps that inner frame's storage separate, because one of its ancestors is from another site, so the frame can't see the value. Playwright launches Chrome with ThirdPartyStoragePartitioning in --disable-features, so the inner frame sees it; tools built on Playwright inherit that, including Patchright 1.64.

The test needs two sites, so it runs only on bot-detector.rebrowser.net and rebrowser-bot-detector.pages.dev (and on 127.0.0.1/localhost for local runs). It runs in Chromium 148 and newer; Safari shares this storage by design, so other browsers are skipped.

Fix: use rebrowser-patches, which re-enables partitioning.

cdpBindingGlobals

CDP Runtime.addBinding puts a native function with an empty name on window. rebrowser-patches 1.1.0 and older used such bindings to find the page's context and left 2–4 of them on every page, with random names. The test watches window for such functions. Page scripts can create functions that look the same, so it's yellow.

Fix: update rebrowser-patches to the latest version.

What is Rebrowser?

This package is sponsored and maintained by Rebrowser. We allow you to scale your browser automation and web scraping in the cloud with hundreds of unique fingerprints.

Our cloud browsers have great success rates and come with nice features such as notifications if your library uses Runtime.Enable during execution or has other red flags that could be improved. Create an account today to get invited to test our bleeding-edge platform and take your automation business to the next level.

Special thanks

kaliiiiiiiiii/brotector

heydryft for the CSS system colour (ActiveText) idea

Chat with me