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.
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 zendriverThen create a simple test script:
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:
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:
User-AgentandSec-Fetch-*checks do not reliably identify it;navigator.webdriversignal.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:
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:
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.