Comment vérifier la cohérence du UserAgent ? Les 4 failles révélées par un UA incohérent

Sur les sites de détection, la ligne UA s'affiche normalement, mais quelques jours après la connexion, la vérification saute à nouveau. Le premier réflexe consiste à changer d'UA ou à installer une extension de plus pour le modifier. Résultat : les anomalies surviennent encore plus souvent.

Ce genre de blocage tient le plus souvent à la cohérence. L'UA n'est qu'un champ, mais la plateforme ne le lit pas à un seul endroit. Si vous ne modifiez que l'un d'eux, les autres gardent la valeur d'origine, et la comparaison fait surgir la contradiction.

Le premier pas d'une vérification d'UA consiste à s'assurer que ce champ tient le même discours sur toutes les surfaces exposées ; ensuite seulement vient la mise en correspondance avec l'appareil, la région et les autres paramètres. Cet article détaille d'abord les trois canaux par lesquels la plateforme lit l'UA, puis énumère les quatre familles de signaux qu'une incohérence finit par exposer. Enfin, une liste de cinq points de contrôle débouche sur la méthode de configuration dans un navigateur d'empreinte.

Les trois canaux par lesquels la plateforme lit l'UA

Une même valeur d'UA, la plateforme la lit en réalité à trois endroits : les en-têtes HTTP, les en-têtes Client Hints et les scripts de la page. Les trois canaux sont indépendants et peuvent chacun être vérifié à part.

Au moment de la requête, la chaîne UA des en-têtes est le canal le plus précoce : le site la lit avant même de servir la page. Depuis Chrome 89, les informations sur l'appareil sont éclatées dans les en-têtes de la série Sec-CH-UA. Marque du navigateur, plateforme et version de plateforme occupent chacun un en-tête, interrogé par le site à la demande. La documentation Client Hints de MDN décrit clairement la structure de ces en-têtes.

Le troisième canal se loge dans les scripts de la page. navigator.userAgent et navigator.userAgentData signalent une nouvelle fois, depuis l'intérieur de la page, les informations du navigateur et de la plateforme. En théorie, les trois lectures coïncident au caractère près. Dès qu'un point est modifié isolément, les deux autres restent inchangés.

C'est précisément là que coincent les extensions de modification d'UA. La plupart ne remplacent que la chaîne UA des en-têtes ; une lecture par script de page renvoie toujours la valeur d'origine, et les deux canaux se contredisent sur-le-champ. Repérer ce type de contradiction n'exige aucune prouesse technique : un script de contrôle des risques qui compare deux lectures suffit.

Un élément de contexte à connaître aussi : Chrome fige progressivement les informations des anciennes chaînes UA, l'arrière du numéro de version est déjà fixé et toujours plus de détails migrent vers Client Hints. La marge de manœuvre sur la seule chaîne UA se resserre ; l'alignement entre canaux devient, lui, toujours plus décisif.

Ce qu'une incohérence d'UA expose : quatre familles de signaux

Pris isolément, un UA n'est ni vrai ni faux ; remis dans la combinaison de signaux, il laisse apparaître les failles. La plupart des incohérences observées quand l'environnement pose problème tombent dans l'une des quatre catégories suivantes.

Première catégorie : des canaux qui se contredisent. Les en-têtes annoncent Chrome 126 tandis que la lecture du script de page en est restée à Chrome 118 ; ou la marque déclarée dans Sec-CH-UA ne correspond pas à ce que renvoie navigator.userAgentData. Une telle lecture n'a pratiquement qu'une seule explication : l'UA a été modifié isolément, et la modification n'a pas couvert tous les canaux.

Deuxième catégorie : une déclaration contredite par le matériel. L'UA indique un iPhone, mais l'écran affiche une résolution de bureau de 1920×1080 avec zéro point de contact ; l'UA déclare Windows, mais le GPU rapporte une puce Apple. Les paramètres matériels sont des mesures issues de l'environnement réel, quand l'UA est une valeur déclarée que l'on peut remplir librement. Mis côte à côte, l'écart saute bien plus aux yeux que l'UA lui-même. Les causes de ces contradictions sont passées en revue paramètre par paramètre dans pourquoi la randomisation des empreintes n'est pas sûre.

Troisième catégorie : une contradiction avec la combinaison d'environnement. L'IP de sortie est aux États-Unis, mais l'UA est celui d'un navigateur en chinois, et la liste des langues comme le fuseau horaire pointent vers une autre région. UA, système, langue, fuseau horaire et IP devraient normalement composer un même profil régional ; dès qu'un élément diverge, tout le profil devient suspect. Changer l'UA ne règle pas ce type de contradiction : c'est la configuration de l'environnement qu'il faut retoucher.

Quatrième catégorie : une incohérence avec les caractéristiques de la couche transport. L'empreinte TLS laissée par la poignée de main évoque un outil automatisé ou un navigateur très ancien, alors que les en-têtes annoncent un Chrome récent. Les caractéristiques de la couche transport sont plus difficiles à déguiser que l'UA, et il ne coûte pas cher à la plateforme de vérifier si les deux se répondent.

Sur les quatre catégories, les trois premières s'évitent dès la phase de configuration de l'environnement ; la quatrième dépend du mode de connexion lui-même. Au quotidien, surveillez les trois premières : dès qu'une contradiction apparaît entre lectures, revenez vérifier la configuration.

Comment se déroule une vérification de cohérence : cinq points de contrôle

Aucun site de détection n'est requis : cinq contrôles, dans l'ordre.

1. Comparaison des canaux : ouvrez une page de détection depuis votre environnement, inspectez dans l'onglet Network des outils de développement l'UA et le Sec-CH-UA des en-têtes, puis confrontez-les à la lecture de navigator.userAgent dans la console : les trois doivent coïncider.

2. Comparaison matérielle : confrontez le type d'appareil déclaré par l'UA, point par point, à la résolution d'écran, aux capacités tactiles, au rendu GPU, au nombre de cœurs et à la mémoire ; si la déclaration annonce un type d'appareil, les mesures doivent y ressembler.

3. Comparaison régionale : langue de l'UA, liste des langues du navigateur, fuseau horaire et IP de sortie doivent relever du même profil régional ; sur mobile, la déclaration doit en outre concorder avec les caractéristiques du réseau mobile.

4. Comparaison des versions : la version du navigateur dans l'UA doit se situer dans la fourchette dominante du marché visé ; plus récente que la dernière, ou figée depuis plusieurs années, elle constitue un signal anormal, et elle doit aussi correspondre au comportement du moteur.

5. Registre de contre-vérification : après chaque ajustement de configuration, repassez la page de détection et archivez les relevés de chaque passe ; lorsque l'environnement affichera une anomalie, ces relevés constitueront le point de départ du diagnostic.

Côté outils, CreepJS recueille justement les contradictions entre les lectures des scripts de page et les valeurs que le navigateur prétend avoir : testé sur un environnement à UA modifié, il signale directement les canaux en conflit. Les sites de détection généralistes comme Browserscan conviennent pour prendre la lecture d'ensemble des cinq paramètres. Utilisez les deux en complément. L'UA n'est qu'un signal parmi ceux de la cohérence de l'environnement ; pour l'ordre de contrôle de l'ensemble, l'article sur la vérification de cohérence anti-association fournit une liste de six points, à croiser avec ces cinq contrôles.

Apparier l'UA dans un navigateur d'empreinte

Pour corriger à partir des cinq points de contrôle, la méthode la plus efficace consiste à générer l'UA avec ses paramètres assortis plutôt qu'à saisir chaque valeur à la main. MostMate est un navigateur d'empreinte IA pensé pour les débutants : il prépare un environnement de navigateur indépendant pour chaque compte, et la cohérence de l'UA s'inscrit naturellement dans son flux de configuration. Avant de vous lancer, vous pouvez parcourir la page de présentation de MostMate pour suivre l'ensemble du processus de création.

À la création d'un environnement, vous choisissez d'abord le système d'exploitation et la version du navigateur ; le User-Agent est généré en conséquence et reste modifiable au besoin. Langue, fuseau horaire et géolocalisation ont par défaut le mode « configuration selon l'IP » : dès que le proxy de sortie est choisi, leur combinaison régionale avec l'UA s'ajuste d'elle-même. Le panneau d'aperçu de l'empreinte liste en temps réel le User-Agent et les valeurs en cours des autres paramètres ; dès la création, vous voyez si l'ensemble de la configuration se tient, sans attendre que l'environnement tourne pour corriger.

La granularité se règle aussi à la main : dans les réglages d'empreinte manuels, onze paramètres comme l'UA, l'écran, le fuseau horaire et la langue se choisissent un à un, tandis que la configuration recommandée de la page d'accueil génère directement un environnement cohérent selon la logique de l'appareil. Chaque voie a ses scénarios.

Précisons la limite : la cohérence entre l'UA et la configuration de l'environnement réduit une catégorie de signaux exposés. Qu'un compte soit ou non associé par la plateforme dépend aussi des règles de la plateforme, des liens entre comptes et du comportement d'utilisation ; la configuration de l'environnement ne traite que la couche environnementale.

Questions fréquentes

Avec une extension qui modifie l'UA, pourquoi est-on plus reconnaissable ?

L'extension ne modifie en général que le canal des en-têtes ; les scripts de page et Client Hints lisent toujours la valeur d'origine. Dès qu'une contradiction apparaît entre canaux, c'est comme si « UA modifié » s'écrivait dans les lectures. La contradiction est en soi un signal anormal, bien plus voyant que l'absence de modification.

Un numéro de version d'UA plus récent est-il forcément meilleur ?

Il suffit de rester dans la fourchette des versions dominantes du marché visé. Plus récent que la dernière version, ou arrêté sur une ancienne vieille de plusieurs années : dans les deux cas, le signal est anormal. La version doit en outre correspondre au comportement du moteur ; courir après la nouveauté n'a aucun intérêt en soi.

Peut-on utiliser un UA mobile dans un environnement de bureau ?

Oui, mais la résolution d'écran, les capacités tactiles, la mémoire de l'appareil et les autres paramètres doivent alors être configurés ensemble comme ceux d'un mobile. Pour voir comment ces paramètres se lient, l'article sur l'empreinte de résolution d'écran et de taille de fenêtre donne les correspondances détaillées.

Si le site de détection affiche un UA cohérent, tout est-il en ordre ?

Les lectures des sites de détection couvrent surtout les paramètres accessibles aux scripts de page ; les caractéristiques de la couche transport et certains détails de Client Hints ne s'y trouvent pas forcément. Mieux vaut conclure après avoir passé les cinq points de contrôle.

Conclusion

L'objectif d'une vérification d'UA, c'est que les trois canaux et l'ensemble de l'environnement se racontent la même histoire : aucun conflit entre canaux, des déclarations qui collent aux mesures matérielles, une combinaison régionale qui tient debout, des versions dans une fourchette plausible. En parcourant les cinq points de contrôle dans l'ordre, la plupart des failles côté UA peuvent être écartées avant la mise en service de l'environnement. Et une vérification faite avant la mise en service coûte le moins cher.

À la création d'un nouvel environnement, faites passer cette vérification avant d'y faire entrer le compte : c'est bien moins pénible que de changer d'UA après avoir essuyé une vérification. Pour gérer vos environnements selon ce flux, vous pouvez télécharger MostMate : de la sélection du système à la configuration du proxy et jusqu'à la vérification de l'aperçu de l'empreinte, réglez l'UA et tout l'environnement en une seule fois.