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.txt.
Valider le format d'un security.txt
Un security.txt est le fichier texte par lequel un site indique à qui a découvert une faille où s'adresser ; son format est arrêté par la RFC 9116. Collez-en le contenu et cet outil contrôle la syntaxe, confirmant que les champs obligatoires tels que `Contact` et `Expires` sont présents et que leurs valeurs prennent la forme requise.
**Ce que l'on néglige volontiers ici, c'est le traitement d'`Expires`.** Non seulement c'est un champ obligatoire, mais **un fichier dont le moment déclaré est passé est tenu pour caduc.** Publiez-le puis n'y touchez plus et, quelques années après, il sera là mais sans effet : il demande donc d'être mené de pair avec un plan de renouvellement. **Son emplacement est lui aussi fixé : il revient à `/.well-known/security.txt`.** Lorsque le fichier est signé, le champ `Canonical` énonce l'adresse qui fait foi, afin que le lecteur puisse s'assurer que nul n'y a touché.
Comment s'en servir
- Collez le contenu de votre security.txt Entrez le fichier entier tel quel.
- Essayez d'abord les exemples Un exemple valide et un exemple comportant des erreurs sont tous deux fournis.
- Lisez les points relevés **Les champs obligatoires absents comme les valeurs mal formées sont les uns et les autres signalés.**
- Vérifiez le moment inscrit dans `Expires` **Confirmez qu'il ne se situe pas dans le passé et décidez à l'avance de la date de renouvellement.**
Astuces pour en tirer le meilleur parti
- L'emplacement officiel de security.txt est
/.well-known/security.txt. 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.
Dans quels cas s'en servir
Pour rendre explicite votre contact de sécurité
Qui découvre quelque chose n'aura pas à chercher une adresse, et le signalement vous parviendra bien plus aisément.
Pour vérifier ce que vous avez publié
**Un fichier mal formé n'en laisse rien paraître au-dehors : seule une validation le révèle.**
Pour prévenir la péremption
Vous pouvez contrôler de loin en loin qu'`Expires` n'est pas échu.
Pour tenir un standard dans l'organisation
Lorsque plusieurs sites sont menés ensemble, vous confirmez qu'ils suivent tous le même format.
Vocabulaire de security.txt
- Contact
- Champ **obligatoire** donnant un moyen de prise de contact : une adresse électronique, un numéro de téléphone ou l'adresse d'un formulaire de signalement.
- Expires
- Champ **obligatoire** au-delà du moment qu'il énonce, le fichier étant alors tenu pour caduc.
- Encryption
- Désigne une clé publique permettant de chiffrer un signalement.
- Policy
- L'adresse d'une page exposant la politique de divulgation des failles.
- Canonical
- L'adresse faisant foi où ce fichier est censé se trouver. **C'est à elle qu'une signature est confrontée.**
- Preferred-Languages
- Énonce les langues dans lesquelles les signalements peuvent être reçus, séparées par des virgules comme dans `en, ja`.
Foire aux questions
https://example.com/.well-known/security.txt 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.txt, 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.