Validateur de security.txt
Collez le contenu de votre security.txt (RFC 9116) pour détecter les erreurs de syntaxe. Vérifie les champs obligatoires comme Contact et Expires ainsi que le format de leurs valeurs, afin de confirmer qu'il est bien publié sur /.well-known/security-text.
Astuces
- L'emplacement officiel de security.txt est
/.well-known/security-text. Par souci de compatibilité, il est utile de publier également une copie à/security.txt(à la racine du site). - Rédigez Contact comme une URI avec un schéma, par exemple mailto:, https: ou tel:. Une simple adresse e-mail sans schéma n'est pas conforme à la RFC 9116 et risque de ne pas être reconnue par les analyseurs automatiques.
- Fixez Expires à un an maximum et prolongez-le à chaque renouvellement. Un fichier expiré risque d'être considéré comme un contact abandonné.
- Toute la validation de cet outil s'effectue entièrement dans votre navigateur : rien de ce que vous collez n'est envoyé vers un serveur, vous pouvez donc vérifier un fichier en toute tranquillité avant de le publier.
Foire aux questions
https://example.com/.well-known/security-text comme emplacement officiel. Comme de nombreuses implémentations vérifient aussi l'ancien chemin https://example.com/security.txt, il est recommandé de le publier aux deux endroits par compatibilité.mailto:[email protected]. Sans schéma, les analyseurs automatiques risquent de ne pas la reconnaître correctement.
Anecdote — L'origine de security.txt — le "premier point de contact" qu'un programme de bug bounty seul ne pouvait pas offrir
security.txt a été proposé en 2017 par les chercheurs en sécurité Ed Overflow et Kagan Baytas. À l'époque, les chercheurs qui découvraient une vulnérabilité n'avaient souvent aucun moyen clair de la signaler, se retrouvant réduits à un formulaire de contact générique ou à un message direct sur les réseaux sociaux. Les signalements mettaient fréquemment longtemps à atteindre la bonne personne, ou étaient tout simplement ignorés.
La proposition a été soumise à l'IETF (Internet Engineering Task Force) et, après des années de discussions et de révisions, elle est devenue la norme officielle RFC 9116 en 2022. Le mécanisme est simple : l'opérateur du site publie un unique fichier texte à /.well-known/security-text, et les chercheurs peuvent déterminer mécaniquement qui contacter, dans quelle langue et selon quelle politique.
De grandes entreprises technologiques comme GitHub, Google, Facebook et LinkedIn ont adopté security.txt, et il est courant de voir un lien vers un programme de divulgation de vulnérabilités ou de bug bounty via le champ Policy. Il fait office de véritable "porte d'entrée" atteignant des chercheurs qui n'auraient peut-être jamais découvert seuls une plateforme de bug bounty.
Dans le prolongement naturel de la RFC 9116, un nombre croissant d'organisations renvoient vers des documents CSAF (Common Security Advisory Framework) via le champ CSAF, standardisant ainsi l'échange des avis de vulnérabilité. security.txt n'est plus un simple fichier de contact : il continue d'évoluer vers un point d'entrée pour l'ensemble du processus de réponse de sécurité d'une organisation.