Detecting Selenium Chrome

Client-side detection is essential in providing complete and accurate bot detection. It’s what enables our solution to detect automated browsers in a single JS challenge execution. Let’s walk through a technique that enables DataDome’s detection engine to specifically detect Chrome browsers created by the Selenium framework by leveraging client-side JavaScript (JS) detection—aka “browser fingerprinting”.

What is Selenium?

Released in 2004, Selenium is a popular framework that uses code to instrument browsers. With Selenium, bot developers can tell a browser what actions to perform (for example, clicking a link or adding a product to a cart). Selenium can be used to instrument various browsers, such as Chrome, Firefox, Opera, and Safari.

Selenium remains a common choice among bot developers, although many have moved to more recent frameworks, such as Puppeteer and Playwright.

Sponsorships Available

Sponsorships Available

Sponsorships Available

How to Detect Selenium Chrome

In bot detection, you can use a wide range of techniques and signals, such as behavioral analysis, TLS fingerprinting, session, and IP reputations, to differentiate humans from automated systems/bots.

In this article, we focus on a technique that enables a website to specifically detect Selenium Chrome—that is, Chrome browsers created by the Selenium framework. The technique we focus on leverages client-side JavaScript (JS) detection, or “browser fingerprinting”.

A straightforward and well-known approach to detecting Selenium is to test if navigator.webdriver is equal to true. However, while navigator.webdriver = true indicates the presence of a bot, it will also catch bots instrumented with  technologies other than Selenium, like Puppeteer and Playwright. Moreover, the navigator.webdriver = true attribute can now be easily forged using the –disable-blink-features=AutomationControlled flag when starting Chrome.

Instead, there’s another approach more specific to Selenium Chrome in which we try to detect side effects introduced by Selenium itself. When Selenium interacts with a web page—either to click on an element, move the mouse, or execute JS code in the context of the page—it will call the JS getPageCache function at some point.

One of the side effects of the JS getPageCache function is that it will define a Cache object in the document object. The cache instance can be accessed through document.$cdc_asdjflasutopfhvcZLmcfl_.

You may wonder why the Selenium developers chose the $cdc_asdjflasutopfhvcZLmcfl_ string. As the developers explain in a code comment, it is a long string that is unlikely to conflict or have a collision with an already existing property name defined in the same JS execution context. 

Thus, testing for the presence of document.$cdc_asdjflasutopfhvcZLmcfl_ can reveal the presence of Selenium Chrome. (Note that the document.$cdc_asdjflasutopfhvcZLmcfl_ property may not be present at load time if the bot hasn’t interacted with the page yet.)

Is my website safe if I detect Selenium Chrome?

It depends on what protection you have in place. While the technique described here allows you to detect the presence of bots automated with Selenium and Chrome, attackers have access to a wide range of bots that leverage other browsers and instrumentation frameworks, such as Puppeteer extra stealth.

Moreover, several developers have come up with ways to bypass the detection technique detailed here, most often either by recompiling the ChromeDriver binary to replace the $cdc_asdjflasutopfhvcZLmcfl_ string with another string, or simply by replacing the string in the compiled binary. 

Modifying different “standard” attributes to avoid detection is more common than you may expect, and impacts all industries, from e-commerce websites to streaming platforms. It’s used by bots to conduct scraping attacks, buy limited edition products (scalping), conduct vote manipulation, and increase the number of views on streaming platforms.

Conclusion

Client-side detection is paramount to fast and accurate bot detection. It enables our bot detection engine to detect automated browsers in a single JS challenge execution by looking for discriminating side effects in browser fingerprints.

As we’ve shown in this article, we can detect (Headless) Chrome bots automated with Selenium using document.$cdc_asdjflasutopfhvcZLmcfl_, even though bots try to hide their presence by removing navigator.webdriver = true using the –disable-blink-features=AutomationControlled flag when starting Chrome.

But keep in mind that detecting and stopping Selenium Chrome is not enough to fully secure a website against bad bots. Today’s attackers still have access to a wide range of bots leveraging other browsers and instrumentation frameworks, such as Puppeteer extra stealth.