security.txt est une bonne pratique de sécurité web formellement normalisée par l'IETF (Internet Engineering Task Force) dans la RFC 9116, visant à fournir aux sites web un moyen unifié et standard de publier leurs informations de contact sécurité. Pour faire simple, c'est un fichier texte placé à un emplacement fixe sur le site web, qui dit aux chercheurs en sécurité (hackers white hat) : « Si vous découvrez une vulnérabilité de sécurité sur mon site, voici comment nous contacter, voici notre clé publique de chiffrement, voici notre politique de divulgation, nous accueillons votre rapport. »
Avant l'apparition de la norme security.txt, les informations de contact sécurité des sites web étaient dispersées et incohérentes. Certains sites n'avaient absolument aucun contact sécurité, d'autres le cachaient dans un coin perdu d'une page, d'autres ne laissaient qu'une adresse i********@********* que personne ne consulte, d'autres encore nécessitaient des démarches compliquées sur LinkedIn pour trouver l'équipe sécurité. Cela posait un problème majeur : lorsque des chercheurs en sécurité de bonne foi découvraient une vulnérabilité, ils ne trouvaient souvent pas le bon canal pour la signaler. Résultat — de nombreuses vulnérabilités restaient ainsi en suspens, non corrigées, jusqu'à ce que des hackers malveillants les découvrent et les exploitent. security.txt est né pour résoudre ce problème du « dernier kilomètre ».
Le concept de security.txt a été initialement proposé en 2017 par les chercheurs en sécurité EdOverflow et Yakov Shafranovich, et a rapidement obtenu un large soutien de l'industrie. En avril 2022, security.txt a été formellement approuvé par l'IETF en tant que norme RFC 9116, devenant une norme de sécurité web internationalement reconnue. Aujourd'hui, de grandes entreprises technologiques comme Google, GitHub, Meta (Facebook), LinkedIn, Cloudflare, ainsi que des organismes gouvernementaux comme le gouvernement britannique, la CISA américaine (Cybersecurity and Infrastructure Security Agency), le gouvernement français (avec les recommandations de l'ANSSI), le gouvernement italien, le gouvernement néerlandais et le centre australien de cybersécurité ont tous déployé security.txt sur leurs sites officiels et recommandent publiquement à d'autres organisations de l'adopter.
La conception principale du fichier security.txt est très simple — c'est un fichier texte brut, composé d'une série de lignes au format « nom-champ: valeur », similaire au format des en-têtes HTTP. La norme définit deux champs obligatoires : Contact (coordonnées de sécurité, plusieurs possibles) et Expires (date d'expiration du fichier) ; ainsi que plusieurs champs optionnels : Encryption (URL de clé publique de chiffrement PGP), Acknowledgments (URL de page de remerciements), Policy (URL de politique de divulgation de vulnérabilités), Hiring (URL de recrutement sécurité), Canonical (URL canonique du fichier), Preferred-Languages (langues acceptées pour les rapports), CSAF (URL de métadonnées du cadre d'avis de sécurité Common Security Advisory Framework). Ce format simple est facile à analyser aussi bien par les humains que par les machines.
Pourquoi déployer security.txt est-il si important ? Tout d'abord, cela réduit la barrière au signalement des vulnérabilités. Les chercheurs en sécurité n'ont pas besoin de passer beaucoup de temps à chercher les coordonnées, ils trouvent en un clic le bon canal de signalement. Deuxièmement, cela démontre une attitude positive envers la sécurité — un site avec security.txt revient à dire « nous accordons de l'importance à la sécurité, nous accueillons les rapports responsables ». Troisièmement, cela réduit le risque que des vulnérabilités soient divulguées publiquement ou exploitées : si les chercheurs disposent d'un canal officiel, ils ne choisiront pas de publier directement la vulnérabilité sur Twitter ou GitHub parce qu'ils n'ont pas réussi à vous contacter. Quatrièmement, dans de nombreuses exigences de régulation sectorielle (finance, santé, gouvernement), la mise en place d'un canal de divulgation de vulnérabilités est devenue une obligation de conformité.
Le déploiement de security.txt nécessite de prêter attention à plusieurs détails clés. Premièrement, le chemin doit être correct : le chemin standard est /.well-known/security.txt, il est également possible de placer une copie à la racine /security.txt comme solution de compatibilité. Le répertoire .well-known est un répertoire standard de « ressources connues » défini par la RFC 8615, d'autres fichiers standard comme robots.txt se trouvent également dans des emplacements associés. Deuxièmement, il doit être accessible en HTTPS, le HTTP en clair étant considéré comme non sécurisé. Troisièmement, le Content-Type doit être text/plain, pas text/html ou un autre type. Quatrièmement, n'effectuez pas de redirection interdomaines sur security.txt — si https://exemple.fr/.well-known/security.txt redirige vers https://autre-domaine.fr/security.txt, les chercheurs et les outils automatisés considéreront cela comme suspect. Cinquièmement, n'oubliez pas de configurer le champ Expires et de le mettre à jour régulièrement, un fichier security.txt expiré sera considéré comme ayant des informations peu fiables.
Le champ Contact est le champ le plus important de security.txt, et le seul qui soit véritablement indispensable (Expires est également obligatoire, mais il ne s'agit que d'un timestamp). Contact prend en charge trois formats d'URI : mailto: pour les adresses e-mail, https:// pour les liens web (comme une page de formulaire de signalement sécurité), tel: pour les numéros de téléphone. Il est fortement recommandé de fournir au moins une adresse e-mail mailto et un lien de formulaire https — le formulaire permet de se protéger contre les spams de robots, tandis que l'adresse e-mail est plus pratique pour les chercheurs qui souhaitent envoyer directement des rapports chiffrés. Plusieurs contacts peuvent être listés sur plusieurs lignes, par exemple en fournissant simultanément l'adresse de l'équipe sécurité, l'adresse du responsable sécurité, un lien vers une plateforme tierce de signalement de vulnérabilités, etc.
Le champ Encryption, bien qu'optionnel, est très important dans la pratique. Lorsqu'un chercheur en sécurité découvre une vulnérabilité grave (comme une fuite de données utilisateurs, une exécution de code à distance), il ne souhaite absolument pas envoyer les détails de la faille dans un e-mail en clair — car l'e-mail traverse plusieurs serveurs pendant la transmission, et n'importe quel maillon peut être écouté. Le chiffrement par clé publique PGP (Pretty Good Privacy) est la méthode de communication sécurisée standard dans l'industrie. Il vous suffit de générer une paire de clés PGP, de placer la clé publique sur votre site web (par exemple /.well-known/pgp-key.txt), puis d'indiquer cette URL dans le champ Encryption. Les chercheurs chiffrent le contenu du rapport avec votre clé publique, et seul le détenteur de la clé privée correspondante pourra le déchiffrer et le lire.
Le champ Policy pointe vers votre page de politique de divulgation de vulnérabilités (Vulnerability Disclosure Policy, VDP), qui est essentielle pour établir la confiance avec les chercheurs. Une bonne VDP doit indiquer clairement : le périmètre de test (quels systèmes sont inclus dans le périmètre de test, lesquels ne le sont pas), les méthodes de test autorisées (par exemple, tests d'injection SQL/XSS autorisés mais DDoS/ingénierie sociale/accès aux données utilisateurs réels interdits), le délai de réponse promis (par exemple « nous accuserons réception de votre rapport dans les 3 jours ouvrables »), si vous proposez des primes aux vulnérabilités, les engagements de sécurité juridique (indication claire que vous ne poursuivrez pas les chercheurs de bonne foi qui respectent les règles), etc. Il existe de nombreux modèles de VDP internationaux, et la CISA américaine propose également un modèle VDP open source.
Au-delà du contact sécurité lui-même, security.txt comporte plusieurs champs « surprises ». Le champ Acknowledgments établit un Hall of Fame (Panthéon de la sécurité) — remerciant publiquement les chercheurs qui vous ont aidé à découvrir des vulnérabilités, c'est une reconnaissance de leur travail et aussi une forme de communauté. Le champ Hiring est une conception très astucieuse : les personnes capables de découvrir des vulnérabilités sur votre site sont elles-mêmes d'excellents talents en sécurité, et placer un lien de recrutement dans security.txt est le canal le plus ciblé pour recruter des experts en sécurité. De nombreuses entreprises ont recruté d'excellents ingénieurs sécurité grâce à security.txt. Le champ Canonical répond quant à lui à un impératif de sécurité — empêcher des attaquants de falsifier votre security.txt sur d'autres domaines.
Concernant la préoccupation fréquente sur le spam, dans la pratique la plupart des organisations ayant déployé security.txt rapportent que l'augmentation du spam est minime. Cela s'explique par : premièrement, les spammeurs ne récupèrent généralement pas d'adresses e-mail en crawlant security.txt ; deuxièmement, vous pouvez utiliser un lien de formulaire https:// au lieu de mettre directement une adresse mailto, et l'ajout d'un CAPTCHA sur le formulaire permet de bloquer complètement les robots ; troisièmement, une adresse e-mail dédiée à la sécurité (par exemple securite@) bénéficie généralement d'un filtrage anti-spam strict. En comparaison, le coût des rapports de vulnérabilités graves manqués faute de canal de contact sécurité est largement supérieur à la légère augmentation potentielle de spam.
Ce générateur est construit en respectant strictement la norme RFC 9116, et tous les formats de sortie sont normalisés : le champ Contact reconnaît automatiquement les préfixes, le champ Expires utilise le format horaire UTC ISO 8601 standard, et Preferred-Languages est automatiquement configuré en fonction de la langue que vous utilisez. Le contenu généré peut être directement copié et déployé sur le chemin /.well-known/security.txt sans aucune modification. Par ailleurs, toute la configuration s'effectue localement dans votre navigateur, aucune donnée n'est envoyée à un serveur — vos informations de contact sécurité restent en permanence sur votre appareil. Déployer security.txt ne prend que 5 minutes, mais le canal de communication sécurité qu'il établit pourra vous aider à éviter un incident de sécurité grave à l'avenir.
