Comparaison entre les navigateurs anti-détection et les Bots-as-a-Service (BaaS)
Les fraudeurs ne cessent d’innover pour contourner les systèmes de sécurité. Ces dernières années, les bots-as-a-service (BaaS) ont permis d’automatiser le scraping pour les cybercriminels. Toutefois, au cours des derniers mois, un nouvel outil de prédilection est apparu : les navigateurs anti-détection. Bien que cette technologie existe depuis un certain temps, elle est désormais plus performante pour le scraping, la revente de billets, le click farming, la création massive de faux comptes, et le recommendation farming. Autrefois utilisés de manière manuelle, ces navigateurs sont désormais automatisés, permettant aux bots d’exploiter leurs fonctionnalités à grande échelle.
Cet article vous présente les navigateurs anti-détection, les différences avec les BaaS, et les méthodes pour les bloquer.
Navigateurs anti-détection vs BaaS : quelles différences ?
À première vue, les BaaS et les navigateurs anti-détection visent tous deux à faciliter les activités frauduleuses en évitant les blocages. Cependant, les navigateurs anti-détection se révèlent bien plus efficaces pour contourner les systèmes de détection par signature, rendant leur identification beaucoup plus complexe.
D’un côté, les BaaS fonctionnent comme un service web « click and collect » : un fraudeur envoie des URL et, si le BaaS réussit, il récupère le contenu des réponses. De l’autre, un navigateur anti-détection doit être installé localement sur l’appareil du fraudeur. Cette différence, bien que subtile, confère aux navigateurs anti-détection un avantage décisif : la possibilité de configurer des paramètres de manière approfondie, ce que les BaaS ne peuvent pas offrir.
Pas de vainqueur incontestable : les empreintes côté serveur
En termes de configuration, les fraudeurs s’intéressent principalement au contrôle d’un ensemble de paramètres – les empreintes digitales côté serveur – pour avoir l’air humain :
- Géolocalisation IP : elle doit idéalement correspondre au pays du site marchand.
- Langue : elle doit être cohérente avec la géolocalisation.
- Référent : il doit correspondre à l’URL visitée (par exemple, l’absence de référent sur une page de panier est anormale).
- User-Agent crédible : souvent la dernière version de Chrome, le navigateur le plus populaire.
- Empreinte TLS : elle doit correspondre au dispositif indiqué par le User-Agent.
- Autres : des en-têtes HTTP et des cookies supplémentaires que les sites web définissent à des fins diverses.
Ces valeurs peuvent être configurées aussi bien par les navigateurs anti-détection que par les fournisseurs de BaaS, ce qui signifie qu’aucune des deux technologies n’a un avantage clair sur ce point.
L’avantage des navigateurs anti-détection : les empreintes côté client
Toutefois, la falsification des empreintes digitales côté serveur ne suffit pas à contourner les protections anti-bots. Un navigateur n’est pas seulement un ensemble de champs dans la requête HTTP, c’est aussi un logiciel avec lequel les humains interagissent. À ce titre, les protections anti-bots collectent également une partie de l’activité du navigateur par le biais de JavaScript (JS), comme les positions et les mouvements de la souris, les empreintes digitales de l’appareil, les capacités du navigateur, etc.
Avec l’analyse approfondie des empreintes côté client, les fraudeurs ont deux options pour simuler plusieurs navigateurs en parallèle : soit ils utilisent un véritable navigateur (sur un appareil physique ou dans une machine virtuelle), soit ils intègrent un navigateur headless dans leur script.
C’est ici que les navigateurs anti-détection offrent un avantage considérable par rapport aux BaaS. Les fraudeurs ne voient pas directement comment un BaaS simule un navigateur ou exécute du JavaScript. Ils envoient simplement leurs URL au BaaS avec quelques en-têtes de requête, puis attendent la réponse. En revanche, les navigateurs anti-détection simulent un profil complet pour chaque tâche :
- Une IP proxy par tâche. Pour le scraping, une tâche = une URL à scraper ; pour la revente de billets, une tâche = un achat ; pour la création de faux comptes, une tâche = une tentative d’inscription, etc.
- Un ensemble d’empreintes côté serveur, cohérentes avec l’appareil indiqué dans le User-Agent.
- Un ensemble d’empreintes côté client, parfaitement compatibles avec les empreintes côté serveur.
Ce niveau de personnalisation rend les navigateurs anti-détection particulièrement efficaces pour imiter des utilisateurs réels tout en contournant les systèmes de détection.
Le concept de une tâche/un profil est essentiel. Par exemple, lors de milliers de tentatives d’inscription, plus un profil (ou une partie de celui-ci) est réutilisé, plus il devient facile à détecter et à bloquer. En d’autres termes, les navigateurs anti-détection isolent tous les signaux qui peuvent représenter un utilisateur unique dans un profil distinct, garantissant que chaque tâche utilise un profil unique.
L’image ci-dessous, tirée de Dolphin-anty, illustre la création d’un profil où chaque empreinte, qu’elle soit côté client ou serveur, peut être configurée pour le navigateur en cours de création. Pour chaque élément, on peut choisir soit la valeur réelle— celle de l’appareil d’origine — soit une valeur falsifiée, définie manuellement ou générée automatiquement par le logiciel.

L’arme secrète des navigateurs anti-détection : la randomisation
Les navigateurs anti-détection permettent également de randomiser certaines empreintes pour générer plusieurs profils indépendants, simulant ainsi plusieurs « utilisateurs » distincts. Par exemple, les solutions anti-bot collectent des informations telles que la taille de l’écran, les capacités audio, les performances graphiques et de rendu, et peuvent soumettre le navigateur à des tests via une balise HTML canvas. Tous ces signaux peuvent être randomisés, rendant chaque profil unique et plus difficile à détecter.
# example on randomizable device fingerprints and capabilities
{
"webGL_renderer":"ANGLE (Intel, Intel(R) HD Graphics 6000 Direct3D11 vs_5_0 ps_5_0, D3D11)",
"webGPU_info": "vendor:intel,architecture:gen-12lp",
"screen_height": 1440,
"screen_width": 2560,
"device_memory": 8,
"color_depth": 24,
...
}
Ainsi, à partir d’un système d’exploitation et d’un nom de navigateur donnés, les navigateurs anti-détection génèrent des profils adaptés en s’appuyant sur leur base de données, qui inclut des informations comme les fournisseurs WebGL, les identifiants de cartes graphiques, etc. Grâce à la randomisation, les fraudeurs peuvent utiliser une multitude de profils uniques et introduire du bruit dans leurs empreintes pour éviter de créer un volume de requêtes suspect émanant du même profil.
Cependant, cette randomisation présente un défi majeur : rester cohérente. La combinaison de toutes les valeurs d’un profil doit toujours imiter un véritable utilisateur sur un appareil réel. Si la cohérence est rompue, tout le bruit ajouté devient inutile, et c’est précisément ce que les systèmes de détection peuvent exploiter pour les bloquer.
Comment bloquer les navigateurs anti-détection ?
La randomisation utilisée par les navigateurs anti-détection complique la tâche des logiciels de protection contre les bots : lorsqu’une signature improbable est enfin repérée, il est souvent trop tard et la fraude peut déjà être commise. Cependant, DataDome utilise des techniques de détection comportementale et repère les incohérences pour identifier ces navigateurs. Par exemple :
- Les navigateurs anti-détection ne gèrent pas eux-mêmes les IP proxy. Les fraudeurs fournissent des listes d’IP ou des clés API à un service de proxy, utilisé ensuite par le logiciel. Deux situations peuvent être détectées :
- Le pool d’IP est trop restreint pour garantir l’unicité des profils, ce qui entraîne des incohérences détectables.
- Le pool d’IP est suffisant, mais les IP proviennent de sources douteuses. Dans ce cas, la détection classique des IP à faible réputation s’applique.
- Les navigateurs anti-détection ne simulent pas de session. Toutes les requêtes liées à une tâche sont exécutées dans un profil isolé. Ainsi, si la séquence de requêtes n’est pas cohérente, la détection comportementale repérera ces anomalies.
- La randomisation peut entraîner des profils incohérents.
- Les identifiants et versions sont souvent générés de manière aléatoire, mais certaines valeurs peuvent être inexistantes ou invraisemblables, ce qui permet aux solutions anti-bot de bloquer les requêtes.
- Des combinaisons peu probables – comme une marque de GPU incompatible avec une empreinte
canvasspécifique – peuvent être détectées et bloquées.
Conclusion
Alors que les BaaS fournissent des outils de type « click and collect » qui facilitent l’accès à la fraude pour les débutants, les navigateurs anti-détection représentent un niveau de sophistication supplémentaire, qui requièrent des compétences avancées pour une configuration optimale. En plus de générer des empreintes très similaires à celles d’un utilisateur humain, la randomisation des profils permet d’augmenter les chances de passer inaperçu. Cependant, la randomisation n’est pas infaillible, et le succès de ces techniques repose en grande partie sur la capacité du fraudeur à simuler également un comportement humain cohérent.