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.
Glossary
WebDriver Detection

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.
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.
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.
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.
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.
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
deniedin headless, while normal browsers showdefault
These inconsistencies form a composite fingerprint for detection.
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_64indicates headless mode - navigator.hardwareConcurrency reporting unrealistic core counts for the claimed device
- navigator.deviceMemory returning undefined or mismatched values
- WebGL renderer strings showing
SwiftShaderorGoogle SwiftShaderinstead of actual GPU names
These mismatches between declared and actual environment are strong automation indicators.
Permission and Sensor API Behavior
Automated browsers handle permissions and sensor APIs differently:
- Permissions.query() for
notifications,camera, ormicrophonereturnsdeniedby default in headless - BatteryManager API is unavailable in headless Chrome, while present in normal browsers
- Sensor APIs like
GyroscopeandAccelerometerare 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.
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.webdriverproperty, which is set totruein automated sessions - The presence of
document.__driver_evaluateordocument.__webdriver_evaluatefunctions - Modified
window.chromeobjects that differ from standard Chrome installations - Altered
navigator.pluginsandnavigator.mimeTypesarrays 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.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Core techniques and adjacent concepts for identifying automated browser sessions and distinguishing bots from genuine human users.
Headless Browser Detection
A set of techniques used to identify web requests originating from browsers running without a graphical user interface. Detection relies on probing for missing rendering artifacts or JavaScript API inconsistencies that occur when no display server is attached.
- Checks for
navigator.webdriverproperty set totrue - Tests for missing plugins like Chrome PDF Viewer
- Evaluates screen dimensions (often 0x0 or unusual defaults)
- Probes for
requestAnimationFrametiming irregularities
Headless Chrome and PhantomJS leave distinct fingerprints that differ from standard user-facing browser installations.
Bot Signature Detection
The process of identifying automated traffic by analyzing non-human behavioral patterns. Bots exhibit telltale signatures that diverge from genuine user interaction.
- Superhuman speed: Form submissions or page transitions faster than human reaction time (< 200ms)
- Perfectly linear mouse movements: Zero curvature or natural jitter in cursor trajectories
- Missing environmental attributes: Absence of standard browser properties like
navigator.pluginsornavigator.mimeTypes - Uniform timing intervals: Requests spaced at exact, non-random intervals
These signatures are often combined with device fingerprinting for higher confidence classification.
Canvas Fingerprinting
A browser fingerprinting technique that exploits the HTML5 Canvas API to render a hidden graphic and capture subtle variations in the device's graphics hardware and driver stack.
- Renders text and geometric shapes to an off-screen canvas element
- Extracts the base64-encoded pixel data via
toDataURL() - Different GPU models, drivers, and OS configurations produce microscopic rendering differences
- Creates a highly stable, unique identifier even when cookies are cleared
WebDriver-controlled browsers often produce canvas fingerprints that differ from standard installations, providing a detection signal.
User Agent Spoofing Detection
The technique of identifying a falsified User-Agent HTTP header string by cross-referencing the claimed browser identity against actual JavaScript engine behaviors and rendering capabilities.
- Compares
navigator.userAgentagainstnavigator.appVersionandnavigator.platform - Tests JavaScript API availability specific to the claimed browser version
- Validates CSS feature support against expected capabilities
- Checks for inconsistencies between HTTP header UA and
navigatorobject UA
Automation tools frequently spoof user agents but fail to replicate the complete behavioral profile of the claimed browser.
TLS Fingerprinting
A method of identifying a client application by analyzing the specific parameters and cipher suites advertised in the Transport Layer Security handshake, creating a signature independent of the IP address.
- Examines the ClientHello message structure
- Catalogs supported TLS versions, cipher suites, extensions, and elliptic curves
- Each browser and automation library produces a distinct TLS fingerprint
- Remains consistent even when IP addresses rotate or user agents change
Selenium and Puppeteer often use default TLS stacks that differ from genuine browser TLS implementations.
Session Fingerprinting
The process of combining behavioral and device attributes collected during a single user session to build a unique, time-bound identifier for detecting session hijacking and replay attacks.
- Aggregates WebDriver detection signals with device fingerprint data
- Monitors behavioral biometrics like mouse dynamics and keystroke patterns
- Tracks session-level consistency of browser properties
- Detects abrupt changes indicating session takeover or tool switching
A session that begins with a clean browser but suddenly exhibits WebDriver properties mid-session is a strong indicator of compromise.

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.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us