Seatext library / BotRefund evidence
How to Identify Playwright and Selenium Traffic
Identify Playwright and Selenium traffic by checking for automation fingerprints: navigator.webdriver flags, CDP debugger leaks, missing human input patterns, and inconsistent browser properties. Combine multiple signals rather than relying on one, because modern stealth...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
Direct answer: what Playwright and Selenium traffic looks like
Playwright and Selenium are browser automation frameworks. They drive a real browser, so the traffic comes from a genuine Chrome, Firefox, or WebKit process. That makes it harder to spot than a simple script using raw HTTP requests. But automation leaves traces.
The most reliable way to identify this traffic is to look for a cluster of signals, not one flag. A single property like navigator.webdriver can be spoofed or hidden by stealth plugins. A combination of browser, network, hardware, and behavior signals is much harder to fake consistently.
Step 1: Check for the WebDriver flag
Both Playwright and Selenium set navigator.webdriver to true by default. This is the fastest first check.
- In JavaScript on your page, run
navigator.webdriver. - If it returns
true, the browser is under automation control. - If it returns
falseorundefined, do not stop. Stealth plugins and patched drivers remove this flag.
Treat this as a tripwire, not a verdict. Many legitimate accessibility tools also set this flag, so combine it with other checks before blocking traffic.
Step 2: Look for CDP debugger leaks
Playwright and Selenium both use the Chrome DevTools Protocol (CDP) to control the browser. This leaves detectable traces.
- Check for
window.chromeproperties that are missing or altered. - Look for
Runtime.enableorPage.enableCDP commands in the browser's debugger state. - Inspect
navigator.pluginsandnavigator.languagesfor inconsistencies with the claimed user agent.
Bot detection services like BotRefund specifically check for "CDP Debugger Leak" as one of their 106 signals. A real user's browser does not expose an active debugging session.
Step 3: Inspect browser property consistency
Automation frameworks often fail to keep every browser property consistent with the claimed environment.
- Compare
navigator.userAgentwithnavigator.platformandnavigator.language. - Check the
Accept-Languageheader against the browser's configured languages. - Verify the timezone reported by JavaScript matches the IP geolocation.
- Look for mismatches between the JavaScript engine version and the claimed browser version.
BotRefund's detection vectors include "HTTP User-Agent Mismatch," "Accept-Language Mismatch," "Timezone Evasion," and "JS Engine Mismatch." These are exactly the inconsistencies that Playwright and Selenium sessions often produce when configured hastily.
Step 4: Analyze behavioral signals
Even a well-configured automation session behaves differently from a human.
- Mouse movement: Playwright and Selenium scripts often move the pointer in straight lines or grid-aligned paths. Humans produce curved, jittery movement.
- Input speed: Automated clicks and keystrokes can happen in under 1 millisecond. A human cannot do that.
- Session duration: Bots often have unnaturally short or perfectly uniform session lengths.
- Engagement: Automated sessions may show no scrolling, no field corrections, and no meaningful page interaction.
BotRefund flags "Robotic linear mouse movements," "Superhuman input speed (<1ms)," "Grid-aligned movement patterns," and "Unnatural session durations." These behavioral patterns are common in Playwright and Selenium traffic because scripts execute actions without human hesitation.
Step 5: Check network and hardware fingerprints
Automation traffic often comes from datacenter IPs, VPNs, or residential proxies that do not match the claimed browser environment.
- Check for WebRTC leaks that reveal a different IP than the HTTP request.
- Look for DNS tunnel leaks where DNS and web traffic take different routes.
- Verify the OS and TCP TTL values match the claimed operating system.
- Check for suspicious ports or IP address inconsistencies.
BotRefund's network vectors include "WebRTC Network Leak," "DNS Tunnel Leak," "OS / TCP TTL Mismatch," and "IP Address Inconsistency." Playwright and Selenium sessions routed through proxies frequently trip these checks.
Step 6: Combine signals into a decision
No single signal is conclusive. A real user might have a VPN. A stealth-configured Playwright script might hide navigator.webdriver. The key is to evaluate the full pattern.
- Collect all available signals for each session.
- Score each signal for how strongly it indicates automation.
- Look for clusters: three or more weak signals together are stronger than one strong signal.
- Use a prediction model or rule engine to classify the session as human or automated.
BotRefund's approach is exactly this: "BotRefund's prediction AI sees how 106 browser, network, hardware, and behavior signals fit together before deciding whether a visit is human or automated." A single suspicious property is not enough; the full pattern matters.
Common mistake: relying on one flag
The most common mistake is blocking traffic based on navigator.webdriver alone. Modern Playwright and Selenium setups use stealth plugins that remove this flag. If you only check one property, you will miss sophisticated automation and may block legitimate users who use accessibility tools.
Instead, collect multiple signals and evaluate them together. This reduces false positives and catches more automation.
How to verify your detection works
Test your detection against known automation traffic.
- Write a simple Playwright script that visits your page.
- Write a simple Selenium script that visits your page.
- Run both scripts and check whether your detection flags them.
- Run a normal human browsing session and check that it is not flagged.
If your detection misses the automation scripts, add more signals. If it flags the human session, tune your thresholds. BotRefund offers a free bot audit that runs a live check on your site, which is a practical way to validate your setup.
Key facts
| Fact | Detail |
|---|---|
| Primary flag | navigator.webdriver is set to true by default in Playwright and Selenium |
| Stealth limitation | Stealth plugins can remove the WebDriver flag, so it is not reliable alone |
| CDP trace | Both frameworks use Chrome DevTools Protocol, leaving debugger leaks |
| Behavioral signals | Straight mouse paths, sub-1ms input speed, and uniform session durations indicate automation |
| Network signals | WebRTC leaks, DNS mismatches, and IP inconsistencies reveal proxied automation |
| Detection approach | Combine 100+ signals for reliable classification; single flags are insufficient |
Limitations and when this advice does not apply
This guidance assumes you control the web page or application receiving the traffic. If you are analyzing server logs from a third-party platform, you may not have access to browser-side signals.
Some legitimate users run browsers with automation-like properties. Accessibility tools, enterprise security software, and remote desktop sessions can trigger false positives. Always allow human review or an appeal path before blocking traffic outright.
Detection is an arms race. Playwright and Selenium maintainers and stealth plugin authors continuously update their tools to evade detection. Your detection logic needs regular updates to stay effective.
FAQ
Can I identify Playwright traffic specifically versus Selenium?
Not reliably from a single signal. Both frameworks use the same underlying browser automation protocols. You can sometimes distinguish them by specific CDP command patterns or default configuration differences, but stealth plugins blur these lines. Focus on identifying automation in general rather than the specific framework.
What is the fastest way to check for automation traffic?
Run navigator.webdriver in the browser console. If it returns true, the browser is under automation control. However, this is only a first check; stealth plugins can hide it.
Do Playwright and Selenium always set navigator.webdriver to true?
By default, yes. But both frameworks allow you to disable this flag, and many stealth plugins do so automatically. Do not rely on it as your only detection method.
Can I block Playwright and Selenium traffic without affecting real users?
Yes, if you use a combination of signals and set conservative thresholds. Blocking based on one flag will cause false positives. A multi-signal approach with human review for borderline cases is safer.
What should I do after identifying automation traffic?
Decide based on your context. For ad traffic, you may want to exclude it from conversion tracking and file a refund claim. For a web application, you may want to block or challenge the session. For analytics, you may want to filter it out of your reports.
How often should I update my detection logic?
Regularly. Automation tools and stealth plugins update frequently. Review your detection signals at least quarterly, and test against the latest Playwright and Selenium versions.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.