CDP Artifacts: Detecting Chrome DevTools Protocol Automation

Nearly every modern browser-automation framework, Puppeteer, Playwright, and undetected-chromedriver among them, drives Chrome through the same low-level channel: the Chrome DevTools Protocol. That shared dependency is a gift to defenders, because CDP leaves runtime artifacts that live below the JavaScript layer where stealth plugins operate, which means one class of detection covers the whole family of tools at once.

Why CDP is the common denominator

CDP is how external code tells Chrome to navigate, evaluate scripts, dispatch input, and read the DOM. Puppeteer speaks it natively, Playwright wraps it, and Selenium’s Chrome driver uses it under the hood. Stealth kits patch page-visible properties, but they cannot change that the browser is being commanded over a debugging protocol, because the commands arrive from outside the page entirely.

The artifacts CDP leaves

Several traces persist regardless of page-level evasion:

1. Execution-context creation timing. When automation injects scripts via Runtime.evaluate, isolated execution contexts are created and torn down with a timing and ordering signature that differs from organic script execution.
2. Exception-handling quirks. How uncaught exceptions and stack traces surface differs subtly when a Runtime domain is attached versus a normal browsing session.
3. Target and session structure. Driving over CDP implies a target being controlled; the way frames, workers, and auxiliary targets are enumerated can betray an attached controller.
4. Serialization behavior. Runtime.evaluate serializes return values through the protocol, and probing objects designed to behave differently under remote serialization can reveal the channel.

None of these are navigator properties, so no stealth module addresses them.

Why page-level patches cannot reach them

Stealth plugins execute as JavaScript at document start. They can redefine navigator.webdriver, wrap native functions, and repaint WebGL strings, all things that live inside the page’s JavaScript environment. CDP artifacts live in the browser process and the protocol between the controller and Chrome. That is architecturally beneath the page, so a script running in the page has no handle to patch it. This is the core reason server-side Smart Signals outrank client-declared properties: the signals that matter most are produced where the bot’s patches cannot operate.

Detecting without tipping your hand

The practical challenge is measuring CDP artifacts without shipping obvious probe code a bot author can find and neutralize. Good detection:

• Uses passive timing measurements that look like ordinary performance instrumentation.
• Probes serialization and exception behavior through constructs that are innocuous to real users but behave differently under a remote controller.
• Correlates several weak CDP signals rather than betting on one, since any single probe can be blinded once discovered.

Because these signals are weak individually and strong in combination, they belong in a weighted score, not a hard rule.

Combining CDP signals with identity

CDP detection is most powerful fused with cross-session correlation. Automation farms run many workers off one image over CDP, so a stable visitorId ties the sessions together across proxy rotation and storage clears. When a cluster of sessions shares both CDP artifacts and a collapsed identity, confidence is very high. Prynt’s reputation network then propagates that finding, so an automation stack detected on one property arrives pre-scored on the next.

The counter-move and why it costs the operator

Sophisticated operators know CDP is detectable and have a response: drive Chrome without CDP at all, using extension-based automation or input injection at the operating-system level. That does close the specific artifacts described here, but it comes at a steep price in capability. CDP is the supported, feature-complete automation interface; giving it up means losing reliable script injection, network interception, and precise control, and forces the operator into slower, more brittle tooling that leaves its own behavioral tells. In other words, the moment CDP detection pushes an operator off the DevTools Protocol, it has already raised their cost and degraded their tooling, which is a win even if that particular session slips through. Detection does not have to be a perfect wall; often it just has to make the cheap, high-quality attack path expensive enough that the economics stop working for the abuser.

A detection recipe

1. Instrument passive timing that captures execution-context and exception signatures.
2. Add low-visibility serialization probes for the Runtime channel.
3. Score CDP artifacts as a weighted cluster, never a single tell.
4. Correlate the visitorId across sessions.
5. Feed confirmed automation into the reputation network.
6. Return reason codes so reviewers see the protocol-level evidence.

The strategic point

Chasing individual navigator tells is an arms race stealth authors win module by module. Detecting CDP artifacts targets the shared foundation the entire automation family stands on, which is far more stable ground. As long as these tools drive Chrome over the DevTools Protocol, and they will, because it is the supported interface, that channel remains detectable.

See how CDP-driven sessions score against live signals in the playground, free to start.