L’évolution de la détection des navigateurs automatisés : un jeu du chat et de la souris

Tout au long de l’histoire de la protection contre les bots, la détection des navigateurs automatisés a toujours occupé une place centrale. Cet article retrace l’évolution de l’automatisation des navigateurs et la bataille permanente entre les développeurs de bots et les stratégies de détection. Des débuts de Selenium aux dernières avancées en matière de contrôle bidirectionnel des navigateurs, nous explorons comment DataDome a su maintenir une longueur d’avance dans cette lutte technologique sans fin.

Pourquoi automatiser les navigateurs ?

La méthode la plus simple pour créer un bot consiste à envoyer des requêtes réseau directes au serveur cible. En comparaison, l’automatisation complète d’un navigateur peut sembler superflue. Alors pourquoi choisir cette approche ?

À mesure que les sites web mettent en œuvre des mesures de protection contre le trafic automatisé, les bots basés sur des requêtes réseau deviennent de moins en moins efficaces. Les protections côté serveur détectent les incohérences dans les en-têtes HTTP, tandis que les protections côté client imposent des défis JavaScript (JS) de « preuve de travail » avant d’autoriser une requête.

Les navigateurs automatisés reproduisent un comportement de navigation humain, envoyant des requêtes avec des en-têtes HTTP authentiques et exécutant le JS comme le ferait un véritable navigateur utilisateur. Cela leur permet de contourner facilement les défenses de base. À première vue, le trafic provenant de navigateurs automatisés est impossible à distinguer du trafic d’utilisateurs humains.

Chez DataDome, la détection de ces navigateurs automatisés sophistiqués est une priorité absolue pour notre équipe en charge de la détection côté client.

Les débuts : Selenium, WebDriver et les premiers signaux

La naissance de Selenium

Avant 2004, l’automatisation des navigateurs était un paysage fragmenté. Les solutions étaient peu fiables et souvent limitées à certains navigateurs ou plateformes spécifiques. La communauté des tests web avait besoin d’un cadre unifié et open-source capable de fonctionner sur différents navigateurs.

C’est ainsi que Selenium est né. Son nom fait référence à l’élément chimique utilisé pour traiter l’empoisonnement au mercure, un clin d’œil à Mercury Interactive, le logiciel de test dominant à l’époque. Selenium se voulait être le remède à l’état actuel de l’automatisation des navigateurs.

L’alliance avec WebDriver

En 2009, Selenium a fusionné avec son principal concurrent, WebDriver. Les meilleurs aspects de chaque projet ont été combinés pour créer une architecture en couches, qui est devenue la norme en matière d’automatisation des navigateurs. Selenium offre une API de haut niveau, tandis que WebDriver agit comme passerelle entre cette API et le navigateur. Chaque fournisseur de navigateur maintient sa propre implémentation de WebDriver (comme ChromeDriver pour Chrome ou GeckoDriver pour Firefox), qui contrôle le navigateur à l’aide de mécanismes internes.

Cette fusion a établi une base solide pour l’automatisation des navigateurs, permettant aux développeurs de créer des bots plus sophistiqués et plus difficiles à détecter.

Source: Springer

Le premier signal

La spécification de WebDriver comprenait un détail qui est devenu historique : l’API Web JavaScript navigator.webdriver était définie comme vraie lorsqu’un navigateur était contrôlé via WebDriver. Cela permettait aux sites web de vérifier cette valeur et de bloquer les requêtes si elle était vraie. Ce drapeau a marqué le début d’un véritable jeu du chat et de la souris entre les développeurs de bots et les techniques de détection.

Les escarmouches de la première génération

Intensification de la détection

Lorsque les bots utilisant WebDriver ont découvert qu’ils étaient détectés via la valeur de navigator.webdriver, ils ont simplement rétabli la valeur false. Cela a rendu nécessaires des méthodes de détection plus avancées.

Chez DataDome, nous avons examiné le code source de Selenium et des drivers, et avons découvert que les navigateurs automatisés laissaient des traces sous forme de variables et d’événements JavaScript, absents lors d’une navigation normale. Nous avons intégré ces vérifications dans notre système, et réussi à bloquer de nouveau les bots qui utilisent ce framework.

Les premiers frameworks d’anti-détection

La communauté des développeurs de bots n’est pas restée passive. Ils ont rapidement développé des frameworks spécialement conçus pour échapper aux nouvelles techniques de détection. Ces outils de « première génération » visaient à masquer les signes révélateurs de l’automatisation.

Notre équipe chez DataDome a analysé le code source de ces frameworks d’anti-détection et a fait une découverte fascinante : dans leurs tentatives pour se cacher, ces outils laissaient derrière eux des empreintes uniques. Cela nous a permis de développer des techniques ciblant précisément ces solutions conçues pour contourner nos systèmes. Ainsi, DataDome a repris l’avantage dans cette bataille continue contre les bots.

Le tournant

Pendant quelques années, la situation est restée relativement stable, jusqu’à un événement marquant en 2013 : Chrome a pris la décision de se détacher du moteur Webkit. Cela leur a permis de faire ce qu’ils voulaient, et a conduit à deux améliorations qui allaient bientôt ébranler les écosystèmes de test web et de botting : Headless Chrome et CDP.

Headless Chrome

En 2017, Chrome a lancé officiellement son mode headless, permettant de faire tourner et d’automatiser le navigateur sans afficher de fenêtre visible. Ce mode a considérablement amélioré les performances et l’évolutivité, que ce soit pour les testeurs ou les créateurs de bots.

Détection des navigateurs headless

Chez DataDome, nous avons rapidement identifié plusieurs signaux clés révélant l’utilisation de Chrome en mode headless :

• plusieurs différences dans les attributs du navigateur, comme l’absence de valeurs dans navigator.plugins et navigator.mimeTypes ;
• le mode headless utilise par défaut un rendu GPU logiciel, détectable via des vérifications spécialisées sur canvas et WebGL.

Nous avons intégré ces contrôles dans notre système de détection pour rester à la pointe de la lutte contre les bots automatisés. Découvrez plus en détail nos méthodes ici.

La révolution du CDP

Chrome DevTools Protocol (CDP)

Alors que la course à la détection s’intensifiait, les fournisseurs de navigateurs travaillaient en coulisses pour améliorer leurs capacités d’automatisation. Au départ, Selenium a automatisé le navigateur en exécutant du JavaScript dans le bac à sable du navigateur. Mais chaque navigateur a progressivement développé un protocole interne, permettant aux drivers d’interagir plus directement avec le navigateur. Le Chrome DevTools Protocol (CDP), initialement conçu pour servir d’interface entre le moteur du navigateur et le panneau DevTools, a rapidement évolué pour devenir un outil puissant d’automatisation de Chrome.

Le CDP est basé sur WebSocket. Il prend en charge la messagerie bidirectionnelle, ce qui permet un contrôle de niveau inférieur, plus direct, du navigateur. Après le fork de Webkit, son développement s’est poursuivi et CDP a atteint un niveau de contrôle bien supérieur à ce qui aurait été possible avec l’ancien WebDriver basé sur HTTP.

Les personnes qui l’ont le mieux compris sont ses créateurs : l’équipe Chrome DevTool. La sortie de Chrome headless a été pour eux le signal d’un mouvement audacieux. Ils ont lancé un tout nouveau cadre d’automatisation pour contrôler Chrome à l’aide de CDP, en contournant complètement WebDriver. Ils l’ont appelé Puppeteer.

Puppeteer a rapidement pris de l’ampleur dans la communauté des développeurs grâce à sa puissance et sa flexibilité.

Puppeteer Extra Stealth

Bien que Puppeteer ait gagné en popularité, il était relativement facile à détecter à ses débuts. Pour répondre à cela, un nouvel outil d’anti-détection a vu le jour : Puppeteer Extra Stealth. Ce plugin a été conçu pour masquer le mode headless ainsi que les signaux spécifiques à Puppeteer, devenant ainsi la solution privilégiée pour contourner les systèmes de détection. Il est rapidement devenu le choix de prédilection des services de bots-as-a-service.

DataDome a immédiatement pris cette nouvelle menace au sérieux. En analysant en profondeur le code source de Puppeteer Extra Stealth, notre équipe a découvert que, tout comme les premiers frameworks d’anti-détection, Puppeteer Extra Stealth laissait des empreintes digitales uniques derrière lui. Nous avons développé une série de techniques innovantes pour détecter son utilisation, et ces méthodes se sont avérées extrêmement efficaces.

Le « nouveau Headless » et le secret du CDP

Le nouveau mode Headless

En 2022, Chrome a lancé une nouvelle version de son mode headless, cinq ans après l’original. Cette mise à jour a rendu obsolètes de nombreuses méthodes de détection utilisées jusque-là. Chez DataDome, nous avons décidé d’adopter une approche différente, en nous concentrant sur l’identification de Puppeteer et en exploitant le protocole CDP qui le sous-tend.

Le signal secret de CDP

Après des recherches approfondies, nous avons développé une technique novatrice permettant de détecter l’utilisation d’une méthode spécifique du protocole CDP dans les navigateurs. Cette technique a permis de bloquer des millions de requêtes malveillantes chaque jour, et ce, pendant plusieurs années. Toutefois, cette méthode a fini par être découverte par la communauté des bots, ce qui a déclenché une nouvelle vague de cadres anti-détection de nouvelle génération visant à la contourner, soit en corrigeant la fuite CDP, soit en réimplantant une interface d’automatisation dans la CDP.

Alors que les frameworks d’anti-détection de troisième génération continuent d’affiner leurs techniques pour rester indétectables, DataDome répond avec de nouvelles stratégies de détection. Même si nous ne pouvons pas dévoiler tous les détails, sachez que nous mettons en œuvre des solutions innovantes et sophistiquées pour déjouer et bloquer les tentatives d’évasion les plus avancées.

L’avenir est bidirectionnel

Le succès de Puppeteer et du protocole CDP de Chrome n’a pas échappé à la communauté des tests web. Un nouveau standard, appelé WebDriver BiDi (pour bidirectionnel), a été développé pour offrir à tous les navigateurs des capacités d’automatisation similaires à celles de CDP.

Source : Groupe de travail WebDriver BiDi

Le passage du WebDriver classique à BiDi est en cours. En 2024, soit 20 ans après la création de Selenium, BiDi est désormais pleinement pris en charge par plusieurs acteurs majeurs comme Google Chrome, Firefox, Puppeteer, et BrowserStack.

Bien entendu, nous suivons de près l’évolution de WebDriver BiDi pour comprendre les nouvelles capacités qu’il offre en matière d’automatisation. Nous nous préparons déjà à anticiper son impact potentiel sur le paysage de la protection contre les bots et sommes prêts à ajuster nos stratégies au fur et à mesure que la technologie progresse. Cela nous permet de rester constamment en avance dans la course à la détection des bots.

Conclusion : l’engagement de DataDome envers une détection des bots toujours plus performante

Le domaine de la détection des navigateurs automatisés est en constante évolution. Depuis les débuts de Selenium jusqu’aux développements les plus récents du contrôle bidirectionnel des navigateurs, chaque avancée dans la technologie d’automatisation a été contrée par des méthodes de détection toujours plus sophistiquées.

Chez DataDome, nous nous engageons à rester à la pointe de cette bataille technologique. Nos équipes d’experts, composées de chercheurs et de développeurs, continuent d’examiner les technologies émergentes, de créer des méthodes de détection de pointe, et de garantir que nos clients sont protégés contre les attaques de bots, même les plus complexes.

En regardant vers l’avenir, une chose est sûre : la course entre les développeurs de bots et les systèmes de détection va se poursuivre. Et DataDome sera là, en première ligne, pour protéger l’écosystème numérique contre ces menaces automatisées.

Envie d’en savoir plus ? Réservez une démo dès maintenant.