Feature request: Detect CDP-driven browsers such as ZenDriver

Start by reproducing the reported bypass with Python 3.13 and zendriver==0.16.0 against a CrowdSec-protected endpoint using the default crowdsecurity/appsec-bot-challenge. Then read the existing browser fingerprinting and challenge behavior; the issue names no source files or tests. Done means a defined CDP-aware detection approach that identifies automation reliably while accounting for false positives from legitimate DevTools use.

What would you like to be added?

CrowdSec's browser bot protection (using default crowdsecurity/appsec-bot-challenge) can currently be bypassed by a browser controlled through the Chrome DevTools Protocol (CDP), for example using ZenDriver.

The important point is that this is not a simple HTTP-client or User-Agent spoofing scenario. ZenDriver launches a genuine Chromium browser and controls it through CDP. As a result, the resulting requests contain what appears to be a legitimate Chrome browser fingerprint and normal browser navigation headers.

For example, accessing a protected endpoint with ZenDriver currently reaches the application behind CrowdSec, is being challenged, succeeds the challenge and accesses the web page.

Reproduction

Using Python 3.13 and zendriver==0.16.0:

virtualenv venv
source venv/bin/activate
pip install zendriver

Then create a simple test script:

import asyncio
import zendriver as zd


async def main():
    browser = await zd.start()
    page = await browser.get("https://your.url.behind.crowdsec.bot.protection.com")
    await asyncio.sleep(10)
    await page.save_screenshot("browserscan.png")
    await browser.stop()


if __name__ == "__main__":
    asyncio.run(main())

When accessing a CrowdSec-protected endpoint, the request reaches the origin/application instead of being identified as an automated browser.

Observed request

The request looks essentially like a normal Chromium navigation:

Sec-Fetch-User: ?1
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br, zstd
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Upgrade-Insecure-Requests: 1
Priority: u=0, i
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Ch-Ua-Platform: "Linux"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36
Sec-Ch-Ua: "Not/A)Brand";v="99", "Chromium";v="148"
Sec-Fetch-Dest: document

Therefore, blocking based on individual request headers does not appear to be a viable solution.

Why this is interesting

ZenDriver differs from traditional Selenium/WebDriver automation because it communicates with Chromium through CDP.

This means that:

• the browser is a real Chromium instance;
• the HTTP request headers look like those generated by a real browser;
• the browser can execute JavaScript normally;
• ordinary User-Agent and Sec-Fetch-* checks do not reliably identify it;
• the automation layer is not necessarily exposed through the traditional navigator.webdriver signal.

This appears to be a more general issue than ZenDriver specifically: CDP-controlled Chromium can potentially defeat a bot-detection mechanism that primarily relies on browser-side fingerprinting and conventional automation indicators.

Feature request

Would it be possible to add stronger detection for CDP-controlled or otherwise externally automated Chromium browsers?

In particular, it would be useful to investigate signals that remain observable from the browser despite the use of a genuine Chromium instance, rather than relying exclusively on HTTP headers or navigator.webdriver.

Potential areas to investigate could include:

• CDP/DevTools-related browser-side signals
• inconsistencies between the main document, iframes and workers
• browser automation artifacts that survive in Chromium despite CDP control
• timing/interaction characteristics associated with automated navigation
• browser capability and API consistency checks
• correlation between browser-side signals and server-side request behavior
• mechanisms for detecting automated browsers that deliberately avoid traditional WebDriver fingerprints

Ideally, this would also cover browsers/tools that intentionally try to avoid automation detection, rather than only standard Selenium/Playwright configurations.

One may also check out https://github.com/cdpdriver/zendriver/issues?q=state%3Aopen%20label%3A%22bot-detection%22

Security impact

The practical impact is that an attacker can use a relatively small Python program to operate a full Chromium browser and access the application behind the CrowdSec protection without apparently triggering the browser challenge.

This is particularly relevant for:

• scraping
• credential-stuffing automation
• automated account creation
• application-layer abuse
• vulnerability scanning
• automated interaction with protected web applications

The attacker does not need to implement a custom HTTP stack or reproduce browser headers manually. A real Chromium instance is sufficient.

Expected behavior

A CDP-controlled Chromium session that exhibits characteristics of browser automation should ideally receive the same treatment as other automated clients, or at least contribute sufficiently strong signals to the bot score that additional verification/challenge is triggered.

At the same time, false positives are obviously important here, since legitimate users can have Chrome DevTools open or use browser extensions and other software that interacts with Chromium.

I'd therefore be interested in whether there are plans for CDP-aware bot detection, or whether the recommended approach is to combine the existing browser fingerprinting with additional server-side behavioral signals.

Why is this needed?

The practical impact is that an attacker can use a relatively small Python program to operate a full Chromium browser and access the application behind the CrowdSec protection without apparently triggering the browser challenge. The attacker does not need to implement a custom HTTP stack or reproduce browser headers manually. A real Chromium instance is sufficient.