Inferensys

Glossary

WebDriver Detection

WebDriver detection is the practice of identifying browser automation frameworks like Selenium or Puppeteer by checking for the presence of specific JavaScript properties and browser flags injected by the automation driver.
Operations team reviewing AI workflow automation on laptop, workflow builder visible, casual office setup.
BROWSER AUTOMATION IDENTIFICATION

What is WebDriver Detection?

WebDriver detection is a passive security technique used to identify browser instances controlled by automation frameworks like Selenium, Puppeteer, or Playwright by inspecting JavaScript properties and browser environment artifacts injected by the driver.

WebDriver detection is the practice of identifying automated browser sessions by probing for the presence of specific JavaScript objects, such as navigator.webdriver, and modified browser flags that are injected when a browser is launched under automation protocol control. These properties are set to true or expose non-standard values, creating a detectable fingerprint that distinguishes scripted clients from genuine human-operated browsers.

This technique is a critical component of bot signature detection and anti-fraud architectures, enabling security systems to block credential stuffing, scraping, and account takeover attempts at the session layer. Advanced detection goes beyond the basic webdriver flag to analyze side-channel artifacts like inconsistent User-Agent strings, missing browser plugins, and the behavior of the Chrome DevTools Protocol runtime.

Browser Automation Fingerprinting

Key WebDriver Detection Signals

WebDriver detection relies on probing for specific JavaScript properties, browser flags, and environmental artifacts injected by automation frameworks like Selenium, Puppeteer, and Playwright. These signals distinguish controlled browser instances from genuine user sessions.

01

navigator.webdriver Property

The most fundamental detection signal. When a browser is under automated control, the navigator.webdriver property is set to true. This is a W3C standard flag that automation tools must set. Genuine user browsers return undefined or false. Detection scripts check this property directly, but sophisticated bots may attempt to override it using JavaScript injection or CDP commands to mask their presence.

W3C Standard
Specification Status
99%+
Detection Accuracy
03

Document Attribute Modifications

Selenium WebDriver modifies the document.documentElement by appending a custom attribute. The attribute name follows the pattern driver-evaluate with a random suffix. Detection involves:

  • Checking document.documentElement.getAttribute() for keys matching known patterns
  • Inspecting the outerHTML of the document element for injected attributes
  • Monitoring for $cdc_ and $chrome_ prefixed attributes that indicate Selenium's presence

These attributes persist even when navigator.webdriver is overridden.

04

Window Object Property Anomalies

Automated browsers exhibit distinct differences in the window object compared to normal instances:

  • window.chrome object: In headless Chrome, this is often empty or missing specific properties like runtime
  • window.navigator.plugins: Headless browsers typically return an empty array with zero length
  • window.outerWidth and window.outerHeight: Often report as 0 in headless mode
  • Notification.permission: Defaults to denied in headless, while normal browsers show default

These inconsistencies form a composite fingerprint for detection.

05

User Agent and Platform Inconsistencies

Cross-referencing the User-Agent string against actual browser capabilities reveals automation:

  • A User-Agent claiming Chrome 120 on Windows, but navigator.platform returning Linux x86_64 indicates headless mode
  • navigator.hardwareConcurrency reporting unrealistic core counts for the claimed device
  • navigator.deviceMemory returning undefined or mismatched values
  • WebGL renderer strings showing SwiftShader or Google SwiftShader instead of actual GPU names

These mismatches between declared and actual environment are strong automation indicators.

06

Permission and Sensor API Behavior

Automated browsers handle permissions and sensor APIs differently:

  • Permissions.query() for notifications, camera, or microphone returns denied by default in headless
  • BatteryManager API is unavailable in headless Chrome, while present in normal browsers
  • Sensor APIs like Gyroscope and Accelerometer are absent or throw errors in emulated environments
  • SpeechSynthesis.getVoices() returns an empty array in headless mode

These API gaps create a detectable profile distinct from genuine user hardware.

WEBDRIVER DETECTION

Frequently Asked Questions

Common questions about identifying browser automation frameworks like Selenium, Puppeteer, and Playwright through JavaScript property inspection and browser flag analysis.

WebDriver detection is the practice of identifying browser automation frameworks—such as Selenium, Puppeteer, or Playwright—by checking for the presence of specific JavaScript properties and browser flags injected by the automation driver. When a browser is launched under automated control, the driver modifies the browser's runtime environment in detectable ways. Detection works by probing for these modifications, including:

  • The navigator.webdriver property, which is set to true in automated sessions
  • The presence of document.__driver_evaluate or document.__webdriver_evaluate functions
  • Modified window.chrome objects that differ from standard Chrome installations
  • Altered navigator.plugins and navigator.mimeTypes arrays that appear empty or contain anomalous entries

These signals collectively form a fingerprint that distinguishes genuine human-operated browsers from scripted sessions, enabling security systems to flag potential bot activity, credential stuffing attacks, or unauthorized scraping attempts.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.