vektr

Rechercher un outil

Recherchez un outil par nom, description ou mot-clé

Vérificateur security.txt et robots.txt

Vérifiez si un domaine publie un fichier security.txt (RFC 9116) et un robots.txt valides, avec leurs champs et directives essentiels.

Ce que fait cet outil

Ce vérificateur regarde deux fichiers texte publics que les sites placent à des emplacements bien connus : security.txt, qui indique comment signaler une vulnérabilité, et robots.txt, qui donne des instructions aux robots d'indexation. Il vérifie leur présence et leurs champs ou directives les plus importants.

security.txt : un canal de signalement standardisé

Avant la RFC 9116, un chercheur en sécurité qui découvrait une faille sur un site devait souvent chercher longuement une adresse de contact valide — formulaire de contact générique, adresse mal surveillée, ou aucune information du tout. security.txt résout ce problème en standardisant un emplacement unique (/.well-known/security.txt) où trouver un contact dédié à la sécurité. Cet outil vérifie aussi le repli historique à la racine (/security.txt), toujours reconnu par de nombreux outils bien que la RFC recommande désormais uniquement l'emplacement .well-known.

Pourquoi la date d'expiration compte autant que le contact

Un fichier security.txt oublié depuis cinq ans, avec une adresse email qui n'existe plus, est pire qu'utile : il donne une fausse impression de canal actif. La RFC 9116 rend le champ Expires obligatoire précisément pour éviter ça — un fichier avec une date expirée signale aux outils automatisés (et aux chercheurs attentifs) que les informations pourraient ne plus être fiables, sans qu'il faille vérifier manuellement chaque champ.

robots.txt : instructions pour les robots, pas une protection

robots.txt indique aux robots bien élevés (moteurs de recherche, outils d'archivage) quelles parties du site ils peuvent explorer — mais c'est une convention respectée volontairement, pas un mécanisme de sécurité. Un robots.txt qui bloque /admin/ ne protège rien : il indique simplement aux robots respectueux de ne pas y aller, tout en révélant publiquement que ce chemin existe à quiconque lit le fichier. La vraie protection d'une zone sensible reste l'authentification, jamais robots.txt.

Le piège classique du Disallow: / oublié

La cause la plus fréquente de désindexation totale et inexpliquée d'un site n'est presque jamais une pénalité algorithmique — c'est un Disallow: / resté actif après une mise en environnement de test, jamais retiré au passage en production. Ce genre d'erreur peut passer inaperçu des semaines, le site continuant à fonctionner normalement pour les visiteurs humains pendant que son trafic de recherche s'effondre silencieusement. Cet outil signale spécifiquement ce cas plutôt que de simplement citer le contenu brut du fichier.

Questions fréquentes

Outils associés