Le 20 août 2026, le développeur Matt Callaghan (blog laserphile) a publié une analyse d'un bug étrange : ses écouteurs Bluetooth avec multipoint cessaient de passer de l'ordinateur au téléphone. Chaque fois qu'un onglet AliExpress était ouvert. Il n'a pas cherché à deviner — il a instrumenté les API du navigateur et a regardé ce qui se passait à l'intérieur de la page. Il s'est avéré que deux scripts obfusqués du stack anti-fraude d'Alibaba activaient le contexte audio et prenaient l'empreinte de l'appareil via un son inaudible.
C'est une illustration parfaite de ce que presque personne ne fait avant de configurer des profils ou de lancer un parseur : ne pas lire le stack de détection du site, mais le deviner. Ci-dessous, une méthode pratique pour créer une carte de détection d'un site spécifique par vous-même, en une heure, sans reverse obfuscation et sans services payants.
Pourquoi créer une carte de détection
Un cycle typique ressemble à ceci : les comptes sont bannis — nous ajustons les paramètres du navigateur anti-détection au hasard — nous changeons de proxy — de nouveau bannis. Entre « bannis » et « paramètres », il n'y a pas de données : il n'est pas clair ce que le site lit exactement et à quel niveau il attrape.
La carte de détection comble ce fossé. C'est une liste : quel fournisseur de protection est en place, quels scripts le mettent en œuvre, quelles API ils touchent et où va le résultat. Ensuite, il devient clair où se situe réellement le goulet d'étranglement — dans l'IP, dans l'empreinte réseau ou dans la couche matérielle du navigateur. Cela est également utile pour trois publics :
- Multi-comptes — comprendre quel signal fusionne les profils. Ils ont des IP différentes, mais la pile audio, le WebGL-renderer et le hardwareConcurrency sont souvent identiques pour toute la ferme.
- Scraping — comprendre s'il vaut la peine de lancer un navigateur ou si la tâche peut être résolue par un client HTTP avec une empreinte TLS correcte.
- Confidentialité — voir ce que le magasin ou le service collecte sur votre appareil en plus des cookies.
Étape 1. Déterminer le fournisseur de protection par le réseau
La première chose à faire est d'ouvrir DevTools sur l'onglet Réseau, de charger la page et de regarder les en-têtes et les cookies du premier document. Les signes distinctifs sont connus et stables :
CF-RAYdans les en-têtes de réponse et le cookiecf_clearance— Cloudflare.- Cookie
_abcket script avec la fonctionbmak— Akamai Bot Manager. - Variables et cookies avec le préfixe
_px— PerimeterX (HUMAN). - Cookie
datadomeet un JS séparé du domaine du fournisseur — DataDome. - Un
429vide sans corps de réponse — signature caractéristique de Kasada.
Si vous n'avez pas envie de le faire manuellement, il existe des détecteurs ouverts comme microlinkhq/is-antibot (30+ fournisseurs) et des extensions de navigateur détecteurs pour 26+ fournisseurs. Ils donnent une réponse rapide, mais ne répondent pas à la question principale — ce qui est réellement mesuré dans votre navigateur. Pour cela, il faut aller plus loin.
Étape 2. Extraire la liste des scripts suspects
Filtrez le Réseau par type JS et notez tout ce qui se charge en dehors du domaine principal ou se trouve dans des répertoires de service. Dans le cas d'AliExpress, il s'agissait de deux fichiers avec des chemins manifestement de service :
assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.jsassets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js
Les signes d'un script anti-fraude : code obfusqué, version dans le chemin, sous-domaine séparé pour la statique, absence de tout lien avec la partie visuelle de la page. Il n'est pas nécessaire d'ouvrir et de lire l'obfuscation — à l'étape suivante, le script se racontera de lui-même.
Étape 3. Instrumenter l'API de fingerprinting
C'est le cœur de la méthode et exactement ce que Callaghan a fait : il a enveloppé le constructeur AudioContext et AudioNode.prototype.connect(), après quoi il a vu deux contextes audio actifs sur la page, où il n'y avait aucun élément multimédia et aucun appel à play().
La logique est simple : vous remplacez la méthode qui vous intéresse par votre propre enveloppe, qui enregistre l'appel avec la pile et passe le contrôle à l'original. La pile d'appels montre quel script a appelé l'API. Il est plus pratique d'insérer un tel extrait via DevTools Sources → Snippets ou via une extension exécutant du code au début du document — il est important d'agir avant le chargement du script anti-fraude.
Un ensemble minimal de pièges qui couvre la plupart des signaux :
HTMLCanvasElement.prototype.toDataURLetgetImageData— empreinte de canvas.WebGLRenderingContext.prototype.getParameter— modèle de carte graphique et de pilote, précision des shaders.AudioContext/OfflineAudioContextetAudioNode.prototype.connect— empreinte audio.- Getters
navigator.hardwareConcurrency,navigator.deviceMemory,navigator.plugins,navigator.webdriver. RTCPeerConnection— WebRTC et adresses locales.screen.width/height,devicePixelRatio,Intl.DateTimeFormat().resolvedOptions()— écran et fuseau horaire.navigator.mediaDevices.enumerateDevices— liste des appareils audio et vidéo.
À l'issue de l'exécution, vous aurez une liste : lesquels de ces API ont été appelés, combien de fois et par qui. Dans le cas analysé, les scripts d'Alibaba touchaient le canvas et toDataURL, le WebGL-renderer et la précision des shaders, l'audio via un oscillateur et un analyseur, les dimensions de l'écran et devicePixelRatio, hardwareConcurrency et deviceMemory, les plugins, le support des codecs, WebRTC, les temps de performance, les motifs de mouvement de la souris et des touches, les capteurs de mouvement de l'appareil et les propriétés indicatives d'automatisation.
Que faisaient exactement les graphiques audio
Il est utile de comprendre à quoi ressemble la mesure pour la reconnaître ailleurs. Le graphique était le suivant : oscillateur en dents de scie → AnalyserNode → ScriptProcessorNode, lisant le résultat de l'analyse → GainNode avec un gain nul → destination. Il n'y a pas de son, le volume n'a pas d'importance — il est tout simplement inexistant. Mais la connexion à destination, selon les termes de l'auteur, oblige le navigateur à traiter activement le graphique, bien que le volume final soit nul. C'est ce chemin audio actif qui a maintenu ouvert le chemin Bluetooth, brisant le changement multipoint des écouteurs.
Les différences dans le traitement de ce signal dépendent du processeur, du matériel audio, du système d'exploitation, du navigateur et des pilotes — d'où un identifiant stable, survivant au changement d'IP et au nettoyage des cookies. Une analyse détaillée de cette couche et des réglages de profils pour elle se trouve dans l'article sur la protection contre le fingerprinting du contexte audio.
Étape 4. Capturer l'envoi du résultat
La collecte sans envoi est inutile, donc la prochaine étape consiste à trouver où va l'empreinte collectée. Filtrez le Réseau par XHR/Fetch et regardez séparément les requêtes de type ping — elles sont générées par navigator.sendBeacon, que les scripts de télémétrie aiment utiliser, car il survit à la sortie de la page.
Il est presque toujours utile d'envelopper également fetch, XMLHttpRequest.prototype.send et navigator.sendBeacon — alors vous verrez le corps de la requête avant qu'il ne parte. Préparez-vous à ce que le contenu soit sérialisé et chiffré : dans le cas d'AliExpress, les données étaient chiffrées avant d'être envoyées à la télémétrie d'Alibaba. Mais même ainsi, vous obtenez deux faits : l'adresse du destinataire et le moment de l'envoi par rapport à vos actions.
Si le site fonctionne non seulement dans le navigateur, mais aussi via une application mobile ou un client séparé, la même question se résout au niveau du trafic, et non du DOM — la méthode d'interception et d'analyse est décrite dans l'analyse de l'audit du trafic via mitmproxy.
Étape 5. Comparer la carte avec votre profil
Maintenant, vous avez une liste de signaux que le site lit réellement. Il reste à vérifier ce que votre profil de travail renvoie sur ces signaux. L'ordre est le suivant : vous prenez les valeurs dans un navigateur normal, puis dans chaque profil anti-détection et comparez.
Deux choses sont importantes en même temps : les valeurs doivent différer entre les profils et être stables à l'intérieur d'un même profil entre les sessions. Un profil dont l'empreinte varie à chaque lancement semble tout aussi suspect pour l'anti-fraude que dix profils avec une empreinte identique.
Vérifiez également que la substitution existe réellement au niveau requis. Ici, la variation entre les navigateurs est révélatrice : Firefox à partir de la version 118 renvoie une sortie constante pour WebAudio, et selon les données de l'analyse, 99,24 % des utilisateurs se résument à trois valeurs ; Brave injecte des données aléatoires et depuis le 22 août 2026 bloque spécifiquement ces scripts d'AliExpress, rappelant que la protection contre le fingerprinting audio est par défaut active depuis plus de six ans ; Safari injecte des erreurs dans les buffers audio ; Chrome n'a pas de protections agressives.
Les pièges
- Le script a déjà eu le temps de fonctionner. Le blocage du fichier ne tue pas le contexte audio déjà créé — l'auteur souligne qu'il faut fermer les onglets ouverts. Il en va de même pour votre instrumentation : si l'enveloppe a été ajoutée après le script, vous ne verrez rien.
- Le blocage casse la fonctionnalité. Le stack anti-fraude répond souvent aussi à des choses légitimes — autorisation, paiement, protection anti-bot contre un véritable abus. Créer une carte de détection et couper des scripts sont des tâches différentes ; la seconde casse le site.
- Il n'y a pas qu'une seule version de la détection. Le stack peut différer selon la géographie, le type d'appareil et le groupe A/B. Il est logique de créer une carte depuis l'IP et l'appareil avec lesquels vous travaillez réellement, sinon vous décrivez une configuration étrangère.
- L'instrumentation elle-même est détectée. Les méthodes natives redéfinies perdent un
toStringcorrect, et un débogueur connecté laisse des traces. Pour le renseignement, ce n'est pas critique, mais ne confondez pas un profil de renseignement avec un profil opérationnel — les techniques de camouflage de l'automatisation sont décrites dans le guide sur le camouflage des navigateurs headless.
Quel proxy est nécessaire pour le résultat
La principale conclusion pratique d'une telle carte est presque toujours la même : l'IP n'est que la première couche, et elle est vérifiée avant toutes les autres. Si l'anti-fraude voit déjà l'adresse d'hébergement au stade de la requête, il ne parviendra tout simplement pas au graphique audio et au canvas — vous recevrez un challenge ou un résultat vide et vous réparerez la mauvaise chose.
Donc, la logique de choix est la suivante. Pour les sites avec un stack sérieux (Akamai, DataDome, PerimeterX, développements internes de niveau Alibaba), la base est constituée de proxies résidentiels — adresses de fournisseurs réels qui ne sont pas filtrés dès le premier filtre. Pour les applications mobiles et les sites où le public principal utilise des smartphones, les proxies mobiles se rapprochent d'un profil naturel : le CGNAT de l'opérateur rend l'adresse délibérément partagée entre de nombreux utilisateurs réels.
Et l'inverse est également vrai : si la carte a montré que le site se limite aux en-têtes et aux cookies, et qu'il n'y a pas de fingerprinting JS lourd, une ferme de navigateurs est superflue, la tâche se résout par un simple client HTTP et des adresses de centre de données.
Conclusion
Le cas des écouteurs est précieux non pas pour le simple fait du fingerprinting audio — cela est connu depuis des années. Ce qui est précieux, c'est la méthode : la personne n'a pas cru aux suppositions, mais a enveloppé deux méthodes de l'API du navigateur et a obtenu en une soirée une liste complète de ce qui est collecté sur lui et l'adresse où cela va. La même technique prend une heure sur n'importe quel site avec lequel vous travaillez et remplace des mois de réglages aléatoires. Créez une carte de détection avant de réparer les bans — sinon, vous risquez de dépenser votre budget en proxies là où le problème était dans le même WebGL-renderer sur tous les profils.
```