Google explore un protocole innovant pour identifier les bots authentiques
Principaux points à retenir :
- Web Bot Auth est un protocole cryptographique en test qui aide les sites web à confirmer qu’un bot est réellement celui qu’il prétend être, en dépassant le simple user-agent.
- Il repose sur des signatures numériques impossibles à imiter par de faux bots, contrairement aux user-agents facilement usurpables.
- Le protocole est encore en développement : Google ne signe pas toutes les requêtes, et les approches traditionnelles (IP, DNS inversé, user-agent) restent essentielles.
- Certains CDN, WAF et services de détection de bots l’adoptent déjà.
Le problème ciblé par Web Bot Auth
Actuellement, n’importe quel bot malveillant peut se faire passer pour Googlebot ou un autre crawler légitime en copiant le bon user-agent. Les administrateurs de sites ont peu de moyens fiables pour distinguer un robot digne de confiance d’un imposteur.
Les méthodes actuelles reposent principalement sur trois éléments : le user-agent (simple chaîne textuelle), l’adresse IP et la vérification DNS inversée. Ces méthodes peuvent être trompées, nécessitent des configurations manuelles entre chaque site et service, et deviennent difficiles à maintenir à grande échelle.
Web Bot Auth de Google cherche précisément à remédier à ces insuffisances.
Qu’est-ce que Web Bot Auth ?
Web Bot Auth, ou HTTP Message Signatures Directory, est une proposition de protocole au sein de l’IETF (Internet Engineering Task Force). Son but est d’automatiser la confiance entre les sites web et les services automatisés les sollicitant.
La logique est simple : au lieu de simplement déclarer son identité via un user-agent, un bot utilisant Web Bot Auth doit prouver cryptographiquement son authenticité. Un bot malveillant imitant un nom de crawler légitime ne pourra pas reproduire cette preuve.
Le protocole fonctionne en trois étapes :
- Utilisation de fichiers de clés standardisés. Les clés publiques sont stockées dans un format universel, le JSON Web Key Set (JWKS), accessible par tout serveur.
- Hébergement à des adresses prévisibles. Les clés sont hébergées à un emplacement défini sur le domaine du service, dans le répertoire /.well-known/, évitant ainsi toute négociation préalable entre le site et le bot.
- Requêtes auto-identifiantes. Chaque requête HTTP émise par un bot participant inclut l’en-tête Signature-Agent, jouant le rôle de carte de visite numérique et pointant vers le répertoire de clés du service.
Pour l’agent de Google, ce répertoire est accessible à https://agent.bot.goog/.well-known/http-message-signatures-directory.
L’impact de la cryptographie
La réelle innovation de Web Bot Auth est de passer d’une identité déclarative à une identité vérifiable. Actuellement, la reconnaissance d’un bot repose sur ses déclarations. Avec ce protocole, elle reposera sur ce qu’il peut démontrer.
Un bot imposteur peut copier un nom, un user-agent ou même une adresse IP, mais ne peut pas reproduire la signature cryptographique associée aux clés privées d’un service légitime. Cette asymétrie rend le protocole potentiellement plus robuste que les mécanismes actuels.
Cependant, le protocole n’est pas un système de liste blanche ou noire automatique. Il fournit un signal fiable sur lequel les administrateurs peuvent s’appuyer pour décider d’autoriser ou de bloquer un bot.
Avantages au-delà de la sécurité
Web Bot Auth ne se limite pas à écarter les mauvais acteurs. Il améliore aussi l’observabilité : les propriétaires de sites peuvent obtenir une vision plus nette de l’interaction des agents automatisés avec leur contenu.
Il simplifie également la gestion à grande échelle. Nouer une relation de confiance avec un service automatisé exige souvent un échange manuel de clés ou de configurations. Web Bot Auth rend ce processus automatique et standardisé, réduisant ainsi les frictions.
Comme le souligne Google, à mesure que les agents IA prolifèrent sur le web, un mécanisme universel de vérification devient essentiel, pas uniquement pour la sécurité.
Implications immédiates pour les administrateurs de sites
Google indique que le protocole est actuellement expérimental. Cela signifie que tous les user-agents Google ne l’utilisent pas encore, et que Google ne signe pas toutes les requêtes. Seul un sous-ensemble du trafic, notamment celui de Google-Agent, est concerné.
Il est crucial de ne pas s’appuyer uniquement sur Web Bot Auth. Une absence de signature n’implique pas forcément qu’un bot est malveillant. Les méthodes traditionnelles doivent rester en place durant le déploiement progressif.
Les développeurs et administrateurs souhaitant mettre en place la vérification doivent :
- Télécharger le jeu de clés publiques depuis https://agent.bot.goog/.well-known/http-message-signatures-directory et les mettre en cache selon l’en-tête Cache-Control, en supprimant les anciennes clés absentes du fichier.
- Vérifier que les requêtes incluent l’en-tête Signature-Agent avec la valeur g= »https://agent.bot.goog ».
- Valider l’en-tête Signature selon le standard HTTP Message Signatures (RFC 9421), en utilisant les en-têtes Signature et Signature-Input avec le label g.
- Maintenir en parallèle la vérification par IP, toutes les requêtes n’étant pas encore signées.
Pour les requêtes sensibles à la latence, Google précise qu’il est possible de retourner la réponse avant la validation complète de la signature et d’appliquer des mesures aux requêtes futures de l’appelant si nécessaire.
Un standard en développement
Web Bot Auth est un projet en cours de développement par le groupe de travail IETF WBA. Le protocole peut évoluer, et Google souligne qu’il est encore à un stade précoce, avec une évaluation continue des implications techniques et de l’impact sur l’écosystème.
Les acteurs souhaitant suivre l’évolution du standard peuvent consulter les travaux du Web Bot Auth Working Group, vérifier avec leur hébergeur s’il prévoit de le prendre en charge (certains CDN, WAF et services de détection de bots l’adoptent déjà), et soumettre des retours à Google via le formulaire dédié.
