Détecter les navigateurs headless : Playwright, Puppeteer et au-delà

Les navigateurs headless sont l'arme de prédilection du web scraping sophistiqué, du credential stuffing et des opérations de fraude. Contrairement aux simples clients HTTP, les navigateurs headless exécutent le JavaScript, rendent les pages et prennent en charge les API web modernes — ce qui les rend bien plus difficiles à détecter. Notre moteur Bot Detection utilise plusieurs méthodes de détection indépendantes pour identifier 15+ frameworks d'automatisation avec des faux positifs proches de zéro.

L'évolution de l'automatisation de navigateur

L'automatisation de navigateur a bien évolué depuis les simples scripts curl. Les outils modernes comme Playwright, Puppeteer et Selenium WebDriver contrôlent de vrais moteurs de navigateur — Chromium, Firefox ou WebKit — en mode headless. Ils exécutent le JavaScript, traitent le CSS, rendent les éléments canvas et gèrent les requêtes WebGL exactement comme les navigateurs headed. Cela les rend invisibles aux méthodes de détection qui se contentent de vérifier la capacité à exécuter du JavaScript.

La dernière génération d'outils est allée plus loin. Le mode furtif de Playwright patche beaucoup des signaux sur lesquels repose la détection de bots traditionnelle. Puppeteer-extra-plugin-stealth modifie les propriétés navigator, écrase les chaînes de vendor WebGL et falsifie les événements d'interaction utilisateur. Ces mesures anti-détection ont créé une course à l'armement entre les opérateurs de bots et les systèmes de détection.

Méthode de détection 1 : analyse du drapeau WebDriver

La propriété navigator.webdriver est mise à true lorsqu'un navigateur est contrôlé par automatisation. La détection précoce se limitait à vérifier cette propriété. Mais les outils furtifs modernes la suppriment ou l'écrasent. Notre détection va plus loin — nous vérifions non seulement la valeur de la propriété, mais aussi son descripteur de propriété, sa présence dans la chaîne de prototypes et si des tentatives ont été faites pour la redéfinir. Nous vérifions également des propriétés associées comme les anomalies de longueur de navigator.plugins qui accompagnent les écrasements de WebDriver.

Méthode de détection 2 : artefacts du Chrome DevTools Protocol

Playwright et Puppeteer contrôlent les navigateurs via le Chrome DevTools Protocol (CDP). Même lorsque le mode furtif est actif, le CDP laisse des artefacts dans le runtime : variables globales spécifiques, fonctions getter modifiées et descripteurs de propriété altérés sur les objets Window et Navigator. Nous sondons ces artefacts à l'aide de techniques résistantes aux simples écrasements.

Méthode de détection 3 : empreinte des navigateurs headless

Chrome headless dispose d'un ensemble de capacités différent de Chrome headed. Il lui manque certains plugins de navigateur, il a des caractéristiques de rendu différentes pour certaines propriétés CSS et il rapporte des valeurs différentes pour certains résultats de MediaQuery. Nous maintenons une base de données de caractéristiques connues des navigateurs headless et confrontons les empreintes entrantes à celle-ci.

Les indicateurs clés de headless incluent : chrome.runtime manquant (présent dans Chrome headed mais absent en headless), tableau navigator.plugins de longueur nulle, schémas de user agent spécifiques qui ont été associés au mode headless dans des versions antérieures, et différences dans la manière dont Chrome headless gère les contextes de sécurité des iframes.

Méthode de détection 4 : analyse de la longueur d'eval

Différents moteurs JavaScript ont des implémentations différentes des fonctions natives, et ces implémentations ont des représentations en chaîne différentes. En vérifiant la longueur de Function.prototype.toString.call(eval) et en la comparant à des valeurs connues pour chaque moteur de navigateur, nous pouvons détecter une usurpation d'environnement — par exemple, une instance de Chrome headless qui prétend être Firefox.

Méthode de détection 5 : validation croisée TLS

Comme évoqué dans notre article sur l'empreinte TLS, le message TLS Client Hello révèle le véritable navigateur ou la véritable bibliothèque HTTP qui établit la connexion. Quand un script Playwright contrôle Chrome, l'empreinte TLS correspond à Chrome — c'est attendu. Mais quand un bot personnalisé utilise une bibliothèque Python requests ou le net/http de Go, l'empreinte TLS révèle la supercherie quelle que soit la chaîne user agent envoyée.

Méthode de détection 6 : analyse du timing et du comportement

Les vrais utilisateurs présentent une variation naturelle dans le timing de leurs interactions. Ils déplacent la souris en courbes, pas en lignes droites. Ils marquent une pause avant de cliquer. Ils scrollent à des vitesses variables. Les outils automatisés, même ceux qui simulent le comportement humain, produisent des schémas statistiquement distinguables — timing trop constant, trajectoires de souris parfaitement linéaires et vitesses de scroll non naturelles.

Nous collectons des signaux comportementaux minimaux durant le processus d'empreinte lui-même — le timing des appels d'API, l'ordre de collecte des signaux et la réactivité de certaines API de navigateur. Ces micro-signaux comportementaux sont difficiles à usurper pour les outils d'automatisation parce qu'ils dépendent de l'environnement d'exécution réel, et non de propriétés écrasables.

Méthode de détection 7 : incohérence de permissions et d'API

Les vrais navigateurs ont des états de permission et une disponibilité d'API cohérents. Un navigateur qui prétend prendre en charge les notifications mais n'a pas de constructeur Notification, ou qui rapporte une résolution d'écran spécifique mais renvoie des valeurs différentes depuis window.screen et les media queries CSS, présente des incohérences qui indiquent une altération ou une émulation.

Nous vérifions des dizaines de ces points de validation croisée, à la recherche de contradictions qui surgissent lorsque les outils d'automatisation écrasent sélectivement certains signaux sans maintenir la cohérence sur toutes les API associées.

Méthode de détection 8 : détection de VM et d'émulation

De nombreuses opérations de bots s'exécutent à l'intérieur de machines virtuelles ou d'instances cloud. Bien que cela seul ne prouve pas l'automatisation, c'est un signal fort combiné à d'autres indicateurs. Nous détectons les VM via des chaînes de renderer WebGL contenant des mots-clés associés aux VM (comme « llvmpipe » ou « SwiftShader »), des caractéristiques matérielles incohérentes avec les appareils grand public (exactement 2 cœurs CPU et 2 Go de mémoire — valeurs par défaut courantes des VM), et des plages d'IP de fournisseurs cloud connus.

L'avantage multi-méthodes

Chaque méthode de détection prise individuellement a ses limites — un opérateur de bots sophistiqué pourrait échapper à n'importe quelle méthode isolée. Mais échapper à toutes les méthodes simultanément, tout en maintenant la cohérence de validation croisée sur l'ensemble, est prohibitivement coûteux. Le coût de développement et de maintenance d'un bot qui passe toutes les vérifications dépasse la valeur économique de la plupart des opérations de bots.

Des faux positifs proches de zéro

Notre détection opère sur un modèle de liste blanche pour les bots de moteurs de recherche (Googlebot, Bingbot, etc.) vérifiés par reverse DNS, et un modèle multi-signaux pour le reste du trafic. Nous exigeons plusieurs signaux corroborants avant de classer un trafic comme automatisé. Cette approche prudente garantit un taux de faux positifs sous 0,1 % — vérifié sur des milliards d'événements en production.