Préparez-vous à la fin des cookies tiers dans Chrome. Testez dès aujourd'hui votre site afin de détecter toute dysfonctionnement.

Cette page a été traduite par l'API Cloud Translation.

Fingerprints

Le fingerprinting consiste à essayer d'identifier un utilisateur lorsqu'il revient sur votre site Web ou d'identifier le même utilisateur sur différents sites Web. De nombreuses caractéristiques peuvent différer entre votre configuration et celle d'un tiers. Par exemple, vous utilisez peut-être un type d'appareil et un navigateur différents, une taille d'écran différente et des polices différentes installées. Si j'ai installé la police Dejavu Sans et que vous ne l'avez pas fait, n'importe quel site Web peut faire la différence entre vous et moi en vérifiant cette police. C'est ainsi que fonctionne l'empreinte digitale : vous créez une collection de ces points de données, et chacun offre plus de moyens de distinguer les utilisateurs.

Une définition plus formelle peut se présenter comme suit: le fingerprinting est l'action qui consiste à utiliser des caractéristiques de longue durée évidentes et non évidentes de la configuration d'un utilisateur pour essayer de le distinguer du plus grand nombre d'utilisateurs possible.

Pourquoi le fingerprinting nuit à la confidentialité des utilisateurs ?

Dans certains cas extrêmes, le fingerprinting d'un utilisateur est important, par exemple pour détecter les fraudes. Toutefois, le fingerprinting peut également être utilisé pour suivre les utilisateurs sur plusieurs sites. Ce suivi est souvent effectué sans que les utilisateurs n'y consentent ou, dans certains cas, sur la base d'un consentement non valide qui n'informe pas l'utilisateur de manière adéquate. Une fois cette analyse effectuée, ces utilisateurs trouveront souvent cette situation inquiétante et se sentiront plutôt trahis.

Le fingerprinting consiste à trouver des moyens de distinguer discrètement un utilisateur d'un autre. Le fingerprinting peut être utilisé pour reconnaître qu'il s'agit toujours du même utilisateur sur le même site Web ou pour reconnaître le même utilisateur dans deux profils de navigateur différents à la fois. Cela signifie que le fingerprinting peut être utilisé pour suivre les utilisateurs sur plusieurs sites. Les méthodes de suivi déterministes et explicites, telles que le stockage d'un cookie avec un ID unique spécifique à l'utilisateur, peuvent être, dans une certaine mesure, observées par les utilisateurs et contrôlées (le module précédent a expliqué certaines de ces approches). Mais le fingerprinting est plus difficile à éviter exactement parce qu'il est dissimulé. Il repose sur des caractéristiques immuables et se produit très probablement de manière invisible. C'est pourquoi on l'appelle « empreintes digitales ». Au mieux, il est difficile de changer votre empreinte digitale, que ce soit votre empreinte digitale ou celle du bout de vos doigts.

Les fournisseurs de navigateurs savent que les utilisateurs n'aiment pas être suivis et mettent continuellement en œuvre des fonctionnalités pour limiter le fingerprinting (dont nous avons parlé dans le module précédent). Dans cet article, nous allons voir comment ces fonctionnalités peuvent avoir une incidence sur les exigences de votre entreprise et vous expliquer comment faire ce que vous voulez tout en protégeant la confidentialité. Il s'agit davantage de l'impact que la protection du navigateur contre le fingerprinting affecte sur vos actions et la manière dont elle vous affecte, plutôt que sur la manière dont elle vous empêche d'utiliser le fingerprinting.

En pratique, la plupart des développeurs et la plupart des entreprises n'ont pas besoin d'empreintes numériques des utilisateurs. Si votre application nécessite que les utilisateurs se connectent, ceux-ci s'identifient auprès de vous, avec leur consentement, et d'une manière qui leur permet de se désinscrire de manière unilatérale à tout moment. Il s'agit d'une méthode protégeant la confidentialité qui permet d'identifier les utilisateurs connectés. Votre application n'exige peut-être pas que les utilisateurs se connectent du tout, ce qui protège encore mieux la confidentialité de vos utilisateurs (et vous ne collectez alors que les données dont vous avez besoin).

À faire

Vérifiez si vos services tiers ne font pas d'empreintes numériques. Dans le module Tiers, vous disposez peut-être déjà d'une liste des services tiers que vous incluez et des requêtes Web qu'ils effectuent. Vous pouvez peut-être inspecter ces requêtes pour voir quelles données sont renvoyées au demandeur, le cas échéant. Cependant, c'est souvent difficile, car l'empreinte numérique est par nature un processus dissimulé qui implique la demande de données qui ne sont pas soumises à l'approbation de l'utilisateur.

Il est également utile de lire les règles de confidentialité de vos services et dépendances tiers pour rechercher des signes d'utilisation du fingerprinting. Elle est parfois appelée "mise en correspondance probabiliste " ou faisant partie d'une suite de techniques de mise en correspondance probabiliste, par opposition à une "correspondance déterministe".

Fonctionnement du fingerprinting

Bien souvent, votre combinaison personnelle de tous ces attributs est propre à vous ou au moins à un petit groupe de personnes similaires. Elle peut être utilisée pour vous suivre discrètement.

Remarque: Le fingerprinting passive et actif

Il est utile ici de faire la distinction entre les techniques de fingerprinting passive et active. Une technique de fingerprinting passive est une technique qui utilise les informations transmises au site Web par défaut. Une technique de fingerprinting active est une technique qui interroge explicitement le navigateur pour obtenir des informations supplémentaires. Cette distinction est importante, car les navigateurs peuvent tenter de détecter, d'intercepter ou de limiter les techniques actives. Les API peuvent être limitées ou faire l'objet d'une passerelle derrière une boîte de dialogue demandant l'autorisation de l'utilisateur (et donc informant l'utilisateur qu'elles sont utilisées ou l'autorisant à les refuser par défaut). Une technique passive est une technique qui utilise des données qui ont déjà été transmises au site Web, souvent parce que par le passé, à l'époque naissante de l'autoroute de l'information, ces informations étaient transmises à tous les sites. La chaîne user-agent en est un exemple. Nous y reviendrons plus en détail par la suite. Il a été considéré comme utile pour fournir de nombreuses informations sur le navigateur, la version et le système d'exploitation de l'utilisateur, afin qu'un site Web puisse choisir d'afficher différents éléments en fonction de ces informations. Cependant, cela augmente également la quantité d'informations distinctives à disposition, qui aident à identifier un utilisateur par rapport à un autre. Ces informations ne sont donc plus disponibles, ou du moins figées, et ne les distinguent plus. Si vous vous basez sur ces informations (par exemple, si vous utilisez différentes branches de code en fonction du user-agent), ce code peut ne plus fonctionner, car les navigateurs bloquent ou arrêtent de plus en plus ces informations. Dans ce cas, les tests constituent la meilleure défense ( voir plus tard).

Annexe: mesurer l'empreinte digitale

La mesure technique de la quantité d'informations fournie par chacun de ces points de données s'appelle entropie et se mesure en bits. Une fonctionnalité comportant de nombreuses valeurs possibles (telles que la liste des polices installées) peut contribuer au total de nombreux bits, ce qui signifie qu'un élément sans grande puissance de distinction (comme le système d'exploitation que vous utilisez) peut n'en ajouter que quelques-uns. L'almanac HTTP décrit comment les bibliothèques de fingerprinting existantes automatisent ce processus consistant à combiner les réponses de nombreuses API différentes dans un "hachage", qui peut n'identifier qu'un petit groupe d'utilisateurs, voire un seul. Maud Nalpas aborde ce sujet en détail dans cette vidéo YouTube. Mais, pour résumer, imaginez que vous voyiez une liste de vos amis avec leur musique préférée, leur plat préféré et les langues qu'ils parlent, mais sans leur nom. Il est fort probable que n'importe quelle liste d'utilisateurs les identifie de manière unique parmi vos amis, ou du moins la réduit à quelques personnes. C'est ainsi que fonctionne le fingerprinting : la liste de choses que vous aimez devient le hachage. Ce hachage permet d'identifier plus facilement un utilisateur comme la même personne sur deux sites non connectés différents. L'objectif du suivi est de contourner le désir de confidentialité de l'utilisateur.

Que font les navigateurs contre le fingerprinting ?

Il est important de noter que les fournisseurs de navigateurs connaissent de nombreuses méthodes permettant à un site Web (ou à un tiers inclus sur un site Web) de calculer une empreinte permettant d'identifier un utilisateur ou d'utiliser des informations différentes pour contribuer à l'unicité de cette empreinte. Certaines de ces méthodes sont explicites et délibérées, comme la chaîne user-agent du navigateur, qui identifie souvent le navigateur, le système d'exploitation et la version utilisée (et qui contribue donc à vous distinguer de moi, si vous et moi utilisons des navigateurs différents). Certaines méthodes ne sont pas délibérément créées pour permettre l'utilisation des empreintes digitales, mais finissent par l'être de toute façon, telles que la liste des polices ou les appareils vidéo et audio disponibles dans le navigateur. (Le navigateur n'a pas besoin d'utiliser ces appareils, il suffit d'obtenir une liste d'appareils par leur nom.) Il est établi que certains contributeurs à une empreinte digitale sont bien après leur publication, comme le rendu exact en pixels de l'anticrénelage des polices sur un élément de canevas. Il y en a beaucoup d'autres, et chaque différence entre votre navigateur et la mienne ajoute de l'entropie. Elle contribue donc potentiellement à faire la différence entre vous et moi, et à identifier une personne de la manière la plus unique possible sur les sites Web. Le site https://amiunique.org possède une longue liste (mais certainement pas exhaustive) de fonctionnalités qui contribuent à la génération d'empreintes digitales, et cette liste ne cesse d'augmenter, même s'il est peu probable que les utilisateurs aient un fort intérêt monétaire.

Non compatible avec certaines API puissantes

La réponse des fournisseurs de navigateurs à toutes ces approches pour calculer l'empreinte d'un utilisateur consiste à trouver des moyens de réduire la quantité d'entropie disponible à partir de ces API. L'option la plus restrictive consiste à ne pas les implémenter dès le départ. Certains navigateurs de premier plan l'ont fait pour diverses API d'appareils et de matériel (comme l'accès NFC et Bluetooth à partir d'applications Web côté client). Les problèmes liés à la confidentialité et au fingerprinting sont cités comme des raisons pour lesquelles ces API n'ont pas été implémentées. Cela peut évidemment affecter vos applications et vos services: vous ne pouvez pas du tout utiliser une API dans un navigateur qui ne l'implémente pas, ce qui peut restreindre ou interrompre complètement la prise en compte de certaines approches matérielles.

Passerelle des autorisations utilisateur

Une deuxième approche adoptée par les fournisseurs de navigateurs consiste à empêcher l'accès aux API ou aux données sans autorisation explicite de l'utilisateur. Cette approche est également souvent utilisée pour des raisons de sécurité : un site Web ne doit pas pouvoir prendre de photos avec votre webcam sans votre autorisation. Mais ici, la confidentialité et la sécurité peuvent avoir des intérêts similaires. Bien sûr, l'identification de la position d'une personne constitue une atteinte à la vie privée, mais elle contribue également au caractère unique d'une empreinte digitale. Exiger l'autorisation de voir la géolocalisation ne réduit pas l'entropie supplémentaire qu'un établissement ajoute à l'unicité de cette empreinte, mais cela évite essentiellement d'utiliser la géolocalisation pour le fingerprinting, car cette opération n'est plus effectuée de manière invisible. L'objectif de l'empreinte digitale est de distinguer substamment les utilisateurs les uns des autres. Si vous êtes prêt à faire savoir à l'utilisateur que vous essayez de l'identifier, vous n'avez pas besoin de techniques de fingerprinting: demandez à l'utilisateur de créer un compte et de s'y connecter.

Ajouter l'imprévisibilité

Dans certains cas, une troisième approche consiste à permettre aux fournisseurs de navigateurs de "fuzzer" les réponses des API afin de les rendre moins précises et donc moins précises. Cette opération a été décrite dans le cadre du mécanisme de réponse aléatoire du module de données, comme vous pouvez le faire lors de la collecte de données auprès des utilisateurs, afin d'éviter de collecter par inadvertance des données permettant d'identifier les utilisateurs. Les fournisseurs de navigateurs peuvent adopter cette approche pour les données API mises à la disposition des applications Web et des tiers. Les API de synchronisation très précises utilisées pour mesurer les performances des pages de window.performance.now() en sont un bon exemple. Le navigateur connaît ces valeurs avec une précision de l'ordre de la microseconde, mais la précision des valeurs renvoyées est délibérément réduite en arrondissant la limite de 20 microsecondes la plus proche afin d'éviter leur utilisation dans le fingerprinting (et pour la sécurité qui évite certes des attaques de synchronisation). L'objectif ici est de s'assurer que les API restent utiles, mais de rendre les réponses moins identifiables: en substance, pour fournir une "immunité collective" en donnant à votre appareil l'apparence de l'appareil des autres au lieu de vous être propre. Safari présente une version simplifiée de la configuration système pour cette raison.

Appliquer un budget dédié à la confidentialité

Privacy Budget est une proposition qui suggère que les navigateurs estiment les informations révélées par chaque surface de fingerprinting. Il n'a pas encore été implémenté dans les navigateurs. L'objectif est de permettre des API puissantes tout en préservant la confidentialité des utilisateurs. En savoir plus sur la proposition de budget pour la confidentialité

Utiliser un environnement de test étendu

Tous ces éléments ont une incidence sur la manière dont vous créez des applications et des services. Dans ce domaine, les réponses et les approches sont particulièrement variées, selon les navigateurs et les plates-formes. Il est donc essentiel de tester votre travail dans plusieurs environnements différents. Bien entendu, cela est toujours important, mais il peut être raisonnable de supposer que le rendu HTML ou CSS sera constant pour un moteur de rendu donné, quel que soit le navigateur ou la plate-forme dans lequel il se trouve (et il peut donc être tentant de tester dans un seul navigateur Blink, par exemple). Ce n'est absolument pas le cas pour l'utilisation des API, car les navigateurs qui partagent un moteur de rendu peuvent différer considérablement de la manière dont ils renforcent la surface de leur API contre le fingerprinting.

À faire

Vérifiez vos propres données analytiques et votre audience pour déterminer l'ensemble de navigateurs à privilégier lors des tests.
Vous pouvez tester les navigateurs suivants : Firefox, Chrome, Edge, Safari sur ordinateur, Chrome et Samsung Internet sur Android et Safari sur iOS. Cela vous permet d'effectuer des tests sur les trois principaux moteurs de rendu (Gecko dans Firefox, avec différentes versions de Blink dans Chrome, Edge et Samsung Internet, et Webkit dans Safari) ainsi que sur les plates-formes mobiles et pour ordinateur.
Si votre site peut également être utilisé sur des appareils moins courants, tels que des tablettes, des montres connectées ou des consoles de jeu, faites-le aussi sur cet appareil. Certaines plates-formes matérielles peuvent être retardées sur les mobiles et les ordinateurs pour les mises à jour des navigateurs, ce qui signifie que certaines API peuvent ne pas être implémentées ou indisponibles dans les navigateurs sur ces plates-formes.
Effectuez le test avec un ou plusieurs navigateurs qui considèrent la confidentialité des utilisateurs comme un facteur de motivation. Incluez les versions préliminaires et de test à venir de vos navigateurs les plus courants, le cas échéant: l'aperçu technologique de Safari, la version Canary de Chrome et la version bêta de Firefox. Vous avez ainsi toutes les chances d'identifier les défaillances de l'API et les modifications qui affectent vos sites avant que ces modifications n'affectent vos utilisateurs. De même, tenez compte de l'environnement de vos utilisateurs en vous référant aux analyses disponibles. Si votre base d'utilisateurs comporte un grand nombre d'anciens téléphones Android, veillez à les inclure dans vos tests. La plupart des utilisateurs ne disposent pas du matériel et des dernières versions rapides dont dispose une équipe de développement.
Effectuez un test à l'aide d'un profil propre et en mode navigation privée. Il est probable que vous ayez déjà accordé les autorisations requises dans votre profil personnel. Vérifiez ce qui se passe si vous refusez l'autorisation d'accéder au site pour une question.
Testez explicitement vos pages en mode protection contre les empreintes digitales de Firefox. Cela permet d'afficher des boîtes de dialogue d'autorisation si votre page tente de prendre des empreintes, ou des données aléatoires pour certaines API. Cela vous permet de vérifier si des tiers inclus dans votre service utilisent des données pouvant être identifiées par empreinte digitale, ou si votre propre service en dépend. Vous pouvez ensuite déterminer si le floutage délibéré rend plus difficile l'exécution de ce dont vous avez besoin. Envisagez d'apporter des corrections en conséquence pour obtenir ces données à partir d'une autre source, vous en passer ou utiliser des données moins précises.
Comme indiqué précédemment dans le module "Tiers", il est également important d'auditer vos dépendances tierces pour voir si elles utilisent des techniques de fingerprinting. Le fingerprinting passive est difficile à détecter (et il est impossible qu'un tiers le fasse sur son serveur). Toutefois, le mode de fingerprinting peut signaler certaines techniques de fingerprinting. De plus, la recherche d'utilisations de navigator.userAgent ou de la création inattendue d'objets <canvas> peut également révéler des approches qui méritent un examen plus approfondi. Il est également utile de rechercher des utilisations du terme "correspondance probabiliste" dans les contenus marketing ou techniques décrivant un tiers. Cela peut parfois indiquer l'utilisation de techniques de fingerprinting.

Outils de test multinavigateurs

Il est difficile d'automatiser les tests de votre code pour des raisons de confidentialité. Les éléments à vérifier lors des tests manuels sont décrits précédemment. Par exemple, que se passe-t-il lorsque vous refusez l'autorisation d'accès au site pour toutes les API auxquelles il tente d'accéder, et comment cette autorisation est-elle présentée à l'utilisateur ? Un test automatisé ne peut pas juger si le site agit de façon à encourager l'utilisateur à lui faire confiance, ou à l'encourager à se méfier de lui, ou à penser qu'un élément est masqué.

Toutefois, une fois le site audité, les tests des API visant à confirmer que tout fonctionne correctement dans les nouvelles versions du navigateur (ou dans les versions "bêta" et "preview") à venir peuvent être automatisés, et devraient être largement intégrés à votre suite de tests existante. Lorsque vous utilisez la couverture de la surface des API, vos outils de test automatisés doivent tenir compte du fait que la plupart des navigateurs permettent un certain contrôle sur les API et les fonctionnalités disponibles. Pour ce faire, Chrome utilise des commutateurs de ligne de commande, tout comme Firefox. Le fait d'y avoir accès lors de la configuration de l'outil de test vous permet d'exécuter certains tests avec des API activées ou désactivées. (Consultez, par exemple, le plug-in de lancement du navigateur de Cypress et le paramètre launch.args de Cypress pour savoir comment ajouter des indicateurs de navigateur lors du lancement.)

Utilisez uniquement la chaîne du user-agent pour des informations grossières

Prenons un autre exemple : depuis le début du Web, les navigateurs envoient une description d'eux-mêmes avec chaque requête dans l'en-tête HTTP User-Agent. Depuis près aussi longtemps, les développeurs Web encouragent les développeurs Web à ne pas utiliser le contenu de l'en-tête du user-agent pour diffuser un contenu différent en fonction du navigateur. Pendant tout ce temps, les développeurs Web le font de toute façon, avec une certaine justification dans certains (mais pas tous). Étant donné que les navigateurs ne veulent pas être isolés pour une expérience non optimale des sites Web, chaque navigateur se fait passer pour n'importe quel autre navigateur, et la chaîne user-agent ressemble à ceci:

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.

Il s'agit, entre autres, de Mozilla/5.0, un navigateur qui a été lancé au moment où les premiers astronautes ont embarqué à la Station spatiale internationale il y a plus de vingt ans. La chaîne user-agent est une source riche d'entropie pour le fingerprinting. Bien entendu, pour limiter cette possibilité d'empreinte, les fabricants de navigateurs ont déjà figé l'en-tête du user-agent, ou s'apprêtent à le faire. Il s'agit d'un autre exemple de modification des données fournies par une API sans nécessairement supprimer complètement l'API. L'envoi d'un en-tête user-agent vide enfreindrait d'innombrables sites Web qui supposent sa présence. En règle générale, les navigateurs suppriment une partie des détails et les conservent pour une grande part. (Notez que cela peut se produire dans Safari, Chrome et Firefox.) Cette protection contre le fingerprinting détaillé signifie essentiellement que vous ne pouvez plus compter sur la précision de l'en-tête du user-agent. Dans ce cas, il est important de trouver d'autres sources de données.

Précisons que les données du user-agent ne disparaissent pas complètement, mais elles sont disponibles avec un niveau de précision inférieur ou elles sont parfois inexactes, car un nombre plus ancien mais immuable peut être indiqué. Par exemple, Firefox, Safari et Chrome limitent le numéro de version indiqué à 10 pour les versions macOS (voir Mise à jour sur la réduction de chaîne user-agent pour en savoir plus). Pour en savoir plus précisément sur la manière dont Chrome prévoit de réduire la quantité de données dans la chaîne user-agent, consultez la page Réduction user-agent. Toutefois, vous pouvez vous attendre à ce que le numéro de version indiqué ne contienne qu'une version majeure (le numéro de version ressemblera donc à 123.0.0.0, même si le navigateur est en version 123.10.45.108), et un petit numéro de version de l'OS sera rétabli sans qu'il y ait une modification des choix. Ainsi, une version imaginaire de Chrome 123.45.67.89 exécutée sur un ordinateur imaginaire "Windows 20" indiquerait son numéro de version comme suit:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Les principales informations dont vous avez besoin (la version du navigateur) restent disponibles: il s'agit de Chrome 123, sous Windows. Toutefois, les informations auxiliaires (l'architecture de la puce, quelle version de Windows, quelle version de Safari il imite, la version mineure du navigateur) ne seront plus disponibles après le gel.

Comparez cela avec un user-agent Chrome "actuel" sur une autre plate-forme:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,

On constate que la seule différence est le numéro de version de Chrome (104) et l'identifiant de la plate-forme.

De même, la chaîne du user-agent de Safari affiche une plate-forme et un numéro de version de Safari, et indique également la version de l'OS sur iOS, mais tout le reste est figé. Ainsi, une version de Safari 1234.5.67 imaginaire exécutée sur un macOS 20 imaginaire peut donner à son user-agent le code suivant:

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,

Sur un appareil iOS 20 imaginaire, il peut s'agir de:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.

Là encore, les informations principales (Safari, sur iOS ou macOS) sont disponibles et iOS Safari fournit toujours un numéro de version iOS, mais la plupart des informations annexes qui étaient disponibles auparavant ont été figées. Il est important de noter que cela inclut le numéro de version Safari, qui n'est pas nécessairement disponible.

Les modifications apportées au user-agent signalé ont fait l'objet de débats passionnés. La page https://github.com/WICG/ua-client-hints#use-cases summarises résume certains arguments et raisons de ce changement. Rowan Merewood propose une présentation avec quelques stratégies permettant de ne plus utiliser le user-agent à des fins de différenciation, dans le contexte de la proposition UA.

Fuzzing

Le "fuzzing" est un terme issu des pratiques de sécurité, où les API sont appelées avec des valeurs inattendues dans l'espoir qu'elles les gèrent mal et qu'elles exposent un problème de sécurité. Les développeurs Web doivent connaître le script intersites (XSS), qui implique l'ajout d'un script malveillant à une page, souvent parce que la page n'échappe pas correctement au code HTML injecté (vous devez donc effectuer une requête de recherche avec le texte <script>). Les développeurs back-end sont conscients de l'injection SQL, dans laquelle les requêtes de base de données qui ne valident pas correctement l'entrée utilisateur présentent des problèmes de sécurité (comme l'illustre l'exemple xkcd avec Little Bobby Tables). Les fuzzing, ou tests à données, sont plus adaptés aux tentatives automatisées qui consistent à fournir de nombreuses entrées non valides ou inattendues à une API, et à vérifier les résultats à la recherche de fuites de sécurité, de plantages ou d'autres problèmes de manipulation. Ce ne sont là que des exemples d'informations délibérément inexactes. Ici, cependant, le comportement est effectué de manière préventive par les navigateurs (en rendant le user-agent délibérément incorrect) afin d'encourager les développeurs à ne plus s'appuyer sur ces données.

À faire

Vérifiez que votre codebase n'est pas dépendant de la chaîne user-agent (une recherche sur navigator.userAgent devrait trouver la plupart des occurrences dans votre code côté client, et le code de votre backend recherchera probablement User-Agent en tant qu'en-tête), y compris vos dépendances.
Si vous trouvez des utilisations dans votre propre code, déterminez ce que le code vérifie et trouvez un autre moyen de faire cette différenciation (ou trouvez une dépendance de remplacement, ou travaillez avec la dépendance en amont en signalant des problèmes ou en vérifiant auprès d'elle pour les mises à jour). Il est parfois nécessaire de différencier les navigateurs pour contourner les bugs, mais le user-agent n'est de plus en plus utilisé comme solution de remplacement une fois qu'il est bloqué.
Vous êtes peut-être en sécurité. Si vous n'utilisez que les valeurs fondamentales de la marque, de la version majeure et de la plate-forme, elles seront presque certainement toujours disponibles et correctes dans la chaîne du user-agent.
MDN décrit les bons moyens d'éviter de dépendre de la chaîne du user-agent ("browser sniffing"), la principale d'entre elles étant la détection de fonctionnalités.
Si vous dépendez d'une manière ou d'une autre de la chaîne du user-agent (même si vous utilisez les quelques valeurs principales qui restent utiles), nous vous recommandons d'effectuer des tests avec les futurs user-agents qui seront disponibles dans les nouvelles versions du navigateur. Il est possible d'effectuer des tests avec ces versions de navigateur à venir à l'aide de versions bêta ou d'aperçu de la technologie, mais il est également possible de définir une chaîne de user-agent personnalisée à des fins de test. Vous pouvez remplacer la chaîne du user-agent dans Chrome, Edge, Firefox et Safari lors du développement local, afin de vérifier comment votre code traite les différentes valeurs de user-agent que vous pouvez recevoir des utilisateurs.

Astuces client

L'une des principales propositions pour fournir ces informations est les User-Agent Client Hints, bien qu'ils ne soient pas compatibles avec tous les navigateurs. Les navigateurs compatibles transmettent trois en-têtes: Sec-CH-UA, qui indique la marque et le numéro de version du navigateur, Sec-CH-UA-Mobile, qui indique si la requête provient d'un appareil mobile, et Sec-CH-UA-Platform, qui indique le système d'exploitation. (L'analyse de ces en-têtes est moins facile qu'il n'y paraît, car il s'agit d'en-têtes structurés et non de chaînes simples, et cela est appliqué par les navigateurs qui envoient des valeurs "difficiles", qui seront traitées de manière incorrecte si elles ne sont pas analysées correctement. Comme précédemment, il s'agit d'un exemple de "test à données aléatoires" effectué de manière préventive par le navigateur. Les développeurs qui utilisent ces données doivent les gérer correctement, car elles sont conçues de sorte qu'une analyse incorrecte ou différée donnera probablement de mauvais résultats, par exemple en montrant des marques qui n'existent pas ou des chaînes qui ne se ferment pas correctement. Heureusement, ces données sont également mises à la disposition de JavaScript directement par le navigateur sous la forme navigator.userAgentData, qui, dans un navigateur compatible, peut ressembler à l'objet suivant:

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}