Générateur et vérificateur de security.txt
Générez un security.txt valide selon la RFC 9116 pour que les chercheurs sachent comment vous joindre, ou collez un fichier existant pour voir ce qui cloche. Une étape de votre préparation au règlement européen sur la cyberrésilience (CRA).
Fonctionne entièrement dans votre navigateur
Générer un security.txt
Vérifier un security.txt
Vérifie uniquement le texte au regard de la RFC 9116. La page ne va pas chercher votre site web (rien de ce que vous saisissez ne quitte cette page : collez donc le fichier), ne vérifie pas une signature OpenPGP et ne teste pas qu'une adresse fonctionne. Un modèle, pas un conseil juridique.
Comment créer et vérifier un security.txt
- Saisissez au moins un Contact (une adresse e-mail, un numéro de téléphone ou une page https://) et contrôlez la date Expires. Renseignez les champs facultatifs qui vous intéressent, comme Policy et Preferred-Languages.
- Copiez le fichier ou téléchargez-le, puis publiez-le à l'adresse
/.well-known/security.txtde votre domaine, en HTTPS et en texte brut. - Pour vérifier un fichier existant, collez son texte dans le vérificateur. Corrigez les erreurs, puis examinez les avertissements. Indiquez l'adresse à laquelle vous le servez pour tester le champ Canonical.
- Mettez un rappel dans votre agenda pour renouveler Expires avant son échéance.
À quoi sert un security.txt
Lorsqu'un chercheur, un client ou un CERT découvre une faille dans votre logiciel, le premier problème est de savoir qui prévenir. Un security.txt est un petit fichier texte placé à une adresse fixe, /.well-known/security.txt, qui répond à cette question : un contact, une date d'expiration et, en option, un lien vers votre politique de divulgation et une clé publique. La RFC 9116 définit le format, et de nombreux scanners, plateformes de bug bounty et CERT nationaux cherchent ce fichier avant toute autre chose.
Pour un éditeur de logiciels de l'UE, il contribue aussi aux obligations du règlement sur la cyberrésilience : l'annexe I attend un moyen publié pour que des tiers signalent des vulnérabilités, ainsi qu'un processus pour les traiter. Le règlement ne nomme pas ce format, mais c'est la manière habituelle de publier le contact. Le guide de déclaration pour les petits éditeurs détaille le reste de la mise en place, y compris le délai de 24 heures.
Les champs
Contact et Expires sont obligatoires. Contact peut apparaître plusieurs fois et doit être un URI : mailto:, tel: ou https:. Expires n'apparaît qu'une fois, sous forme de date et d'heure comme 2027-12-31T23:59:59Z, et la RFC 9116 demande une échéance à moins d'un an. Encryption, Acknowledgments, Policy, Hiring et Canonical sont des liens facultatifs, et toute adresse web doit utiliser https. Preferred-Languages n'apparaît qu'une fois et liste des codes de langue. Les champs que la RFC ne définit pas sont ignorés par les lecteurs ; le vérificateur les signale donc par un avertissement, car il s'agit le plus souvent de fautes de frappe.
Conseils
- Utilisez une boîte aux lettres lue par plusieurs personnes plutôt que l'adresse d'une seule, et testez-la en lui écrivant.
- Rédigez une politique de divulgation des vulnérabilités et liez-la avec le champ Policy.
- Connaissez vos délais avant qu'un signalement n'arrive : l'horloge de 24 heures du CRA transforme une heure de prise de connaissance en échéances datées.
Questions fréquentes
Le règlement sur la cyberrésilience impose-t-il un security.txt ?
Non. Le règlement attend des fabricants qu'ils aient une politique de divulgation coordonnée des vulnérabilités et un moyen publié de signaler des vulnérabilités. Un fichier security.txt est la manière courante de publier ce contact, et les professionnels le recommandent, mais le règlement ne nomme pas ce format. Voir le guide pour les petits éditeurs.
Où placer exactement le fichier ?
À l'adresse https://votre-domaine/.well-known/security.txt, servi en HTTPS avec le type de contenu text/plain; charset=utf-8. La RFC 9116 autorise aussi une copie à l'adresse /security.txt pour les installations plus anciennes. Publiez-le sur chaque domaine ou sous-domaine que vous voulez couvrir.
À quelle échéance fixer Expires ?
La RFC 9116 indique qu'elle doit se situer à moins d'un an dans le futur, afin que les chercheurs puissent se fier à des coordonnées tenues à jour. Le générateur propose par défaut un peu moins d'un an. Une fois la date dépassée, les lecteurs sont invités à ignorer le fichier : renouvelez-le à temps.
Dois-je signer le fichier avec PGP ?
Non, la signature est facultative mais recommandée. Un fichier signé est un message OpenPGP signé en clair, créé avec gpg --clearsign security.txt. Le vérificateur reconnaît le format signé et en contrôle la structure, mais il ne peut pas vérifier la signature elle-même ; utilisez gpg --verify pour cela.
Pourquoi le vérificateur ne peut-il pas aller chercher mon site ?
Pour préserver la confidentialité : la page fonctionne entièrement dans votre navigateur et n'envoie aucune requête à d'autres sites. Ouvrez votre fichier dans un onglet, copiez le texte et collez-le ici. Vous contrôlez ainsi aussi ce que les visiteurs reçoivent réellement.
À quoi sert le champ Canonical ?
Il liste les adresses où le fichier est censé être servi, afin qu'un lecteur puisse confirmer qu'un fichier trouvé à une adresse lui appartient bien. Si vous saisissez l'adresse à laquelle vous servez le fichier, le vérificateur teste que l'une de vos lignes Canonical y correspond.