Vérificateur security.txt

Tapez un domaine : vous voyez s’il publie un security.txt, le fichier qui dit aux chercheurs en sécurité comment signaler une vulnérabilité, et si ce fichier respecte la RFC 9116. Un fichier expiré ou mal formé est ignoré par les outils qui le lisent.

Notre serveur récupère un seul fichier, le security.txt du domaine que vous tapez (à son adresse standard, puis à l’ancienne), et garde la réponse dix minutes.

Ce que regarde le vérificateur

L’emplacement: Le fichier doit se trouver à https://votredomaine/.well-known/security.txt. L’ancien emplacement, /security.txt à la racine, est lu en secours et signalé.
Le champ Contact: Obligatoire, au moins une fois : une adresse écrite en mailto:, https: ou tel:. L’adresse e-mail nue, sans mailto:, est l’erreur la plus courante.
Le champ Expires: Obligatoire, une seule fois, sous forme de date et heure complètes (2027-06-30T00:00:00Z). Passé cette date, le fichier est considéré comme périmé ; la RFC 9116 recommande une date à moins d’un an.
Le reste: Le type de contenu (text/plain), les adresses web en https, le champ Canonical face à l’adresse lue, Preferred-Languages donné une seule fois, et les lignes qui ne sont pas des champs.

Comment lire le résultat

Valide: Un contact, une date d’expiration à venir, et rien qui casse le format. Notez le renouvellement dans votre agenda : c’est la date qui finit par poser problème.
Expiré: Le fichier était juste, et personne ne l’a renouvelé. Changez la date Expires, et vérifiez au passage que le contact arrive encore à quelqu’un.
Non valide, ou absent: Les constats disent quel champ manque ou est mal formé. Sans fichier, un chercheur qui trouve une faille doit deviner une adresse, et renonce souvent.

Les erreurs que l’on rencontre

Ce qui rend le plus souvent un security.txt inutile, et comment le corriger.

Le fichier a expiré

Pourquoi. Expires est obligatoire et a été fixé une fois, en général à un an. Rien ne vous prévient quand la date passe.

Correction. Fixez une nouvelle date à moins d’un an et ajoutez un rappel. Si le fichier est produit par votre site, calculez la date au déploiement.

Contact est une adresse e-mail nue

Pourquoi. Le champ attend une adresse avec son préfixe. « security@acme.org » seul n’en est pas une, et les outils stricts rejettent le fichier.

Correction. Écrivez « Contact: mailto:security@acme.org ». Utilisez une boîte partagée que quelqu’un lit, pas l’adresse d’une personne.

L’adresse répond par la page d’accueil

Pourquoi. Le site renvoie toute adresse inconnue vers une page avec un statut 200 : le fichier semble exister, et c’est en fait une page web.

Correction. Publiez un vrai fichier texte à /.well-known/security.txt, servi en text/plain, et laissez les adresses inconnues répondre 404.

Questions

À quoi sert security.txt ?

Il donne à ceux qui trouvent une vulnérabilité dans votre site ou vos systèmes un moyen de vous le dire : une adresse, éventuellement une politique et une clé de chiffrement. Sans lui, les signalements se perdent ou deviennent publics.

Est-il obligatoire ?

Aucune loi ne l’impose de façon générale. Plusieurs États le demandent à leurs propres sites, et les clients qui évaluent leurs fournisseurs le recherchent de plus en plus.

Le fichier doit-il être signé ?

Non. La signature OpenPGP est facultative ; le vérificateur note sa présence sans la vérifier.

Qu’envoyez-vous à vos serveurs ?

Le domaine que vous tapez. Notre serveur récupère le fichier à ses deux adresses possibles, car un navigateur ne peut pas le lire depuis un autre site ; la réponse est gardée dix minutes. Voir la politique de confidentialité.