Vérification de security.txt
Entrez un site pour voir s’il indique aux chercheurs en sécurité où signaler un problème et si ce fichier est au bon endroit, bien formé et encore valide. S’il n’y en a pas, vous pouvez le rédiger plus bas.
Rédiger un security.txt
Remplissez ce qui s’applique et copiez le résultat. Le fichier est assemblé dans cette page : rien de ce que vous tapez ici ne nous est envoyé.
Une adresse e-mail ou l’adresse https:// d’un formulaire. Utilisez une boîte partagée, pas une personne : les gens partent.
Une page qui indique ce qui peut être testé et ce qu’une personne qui signale peut attendre de vous.
Codes de langue séparés par des virgules.
Ajoute une ligne Canonical, qui lie le fichier à son adresse.
Préréglé à un an à partir d’aujourd’hui, le maximum recommandé par la norme.
- Enregistrez le texte dans un fichier nommé
security.txt, encodé en UTF-8. - Téléversez-le dans un dossier nommé
.well-knownà la racine du site, pour qu’il réponde à l’adressehttps://your-domain/.well-known/security.txt. - Lancez la vérification ci-dessus : le fichier doit être renvoyé en HTTPS avec le type
text/plain. - Notez la date d’expiration dans un calendrier. Un fichier expiré est pire que pas de fichier, parce qu’il a l’air abandonné.
Une porte d’entrée pour les mauvaises nouvelles
Tôt ou tard, quelqu’un à l’extérieur de votre organisation repère quelque chose d’anormal sur votre site : une page qui affiche les commandes d’autres clients, un panneau d’administration oublié, une réinitialisation de mot de passe qui peut être rejouée. La plupart de ces personnes veulent vous le dire. Le plus dur est de trouver à qui. Le formulaire de contact va aux ventes, le chat d’assistance veut un numéro de commande et personne ne répond à info@.
Un fichier security.txt règle ce seul problème. Ce sont quelques lignes de texte brut à une adresse fixe, /.well-known/security.txt, qui disent où envoyer les signalements et jusqu’à quand cette information vaut. Le format a été publié en 2022 sous le nom RFC 9116. Les scanners, les plateformes de bug bounty et les agences nationales de sécurité lisent le fichier automatiquement quand ils ont quelque chose à transmettre.
Contact: mailto:security@example.com
Expires: 2027-01-31T00:00:00.000Z
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policyCe que cette vérification lit
Notre serveur demande https://your-host/.well-known/security.txt, puis l’ancienne adresse /security.txt à la racine si la première ne renvoie rien. Les redirections sont suivies. Une réponse de statut 200 qui se révèle être une page HTML compte comme une absence de fichier, car beaucoup de sites répondent à toute adresse inconnue par leur page d’accueil.
Quand il y a un fichier, nous le jugeons sur trois points.
| Élément | Ce qui doit être vrai |
|---|---|
| Comment il est servi | À l’adresse /.well-known/, en HTTPS, avec Content-Type: text/plain. Une redirection vers un autre domaine est signalée. |
Contact | Au moins un, chacun sous forme d’URI : mailto:, https:// ou tel:. Une adresse e-mail seule, sans mailto:, est une erreur. |
Expires | Un seul exactement, écrit sous forme d’horodatage complet comme 2027-01-31T00:00:00.000Z, dans le futur. Expiré est une erreur ; moins de 30 jours restants ou plus d’un an d’avance est un avertissement. |
| Champs facultatifs | Encryption, Acknowledgments, Policy, Hiring et CSAF doivent être des adresses https://. Preferred-Languages apparaît une fois et contient des codes de langue. Canonical doit inclure l’adresse d’où le fichier a été lu. |
Les noms de champ hors norme sont listés sans pénalité, car les extensions sont permises. La vérification dit aussi si le texte est enveloppé dans une signature en clair OpenPGP. Elle ne vérifie pas cette signature.
Les erreurs que nous voyons le plus
- Une date expirée
- Quelqu’un a écrit le fichier une fois puis l’a oublié. La RFC 9116 dit qu’un fichier expiré ne doit pas être utilisé et la personne qui veut signaler un problème en est réduite à deviner. Le renouveler prend deux minutes : confirmez les contacts, repoussez la date, publiez.
- Aucun
Expires - Les fichiers écrits avant 2022 suivaient un brouillon où le champ était facultatif. Il est obligatoire maintenant.
Contact: security@example.com- La valeur doit être une URI. Écrivez
mailto:security@example.com. - Le fichier seulement à la racine
/security.txtest un secours. Mettez le fichier dans/.well-known/et redirigez l’ancienne adresse vers lui.- Un
Canonicalcopié d’un autre site - Si le champ est là et ne liste pas l’adresse d’où le fichier est servi, le fichier se contredit lui-même.
En publier un que vous pouvez garder à jour
Commencez par décider qui lit la boîte aux lettres. Une adresse partagée comme security@ qui atteint deux personnes vaut mieux qu’une personne nommée. Utilisez ensuite le générateur de cette page. Il ajoute mailto: là où il faut, met la date en forme et la préréglage à un an.
Envoyez le résultat dans un dossier nommé .well-known à la racine web. La plupart des serveurs envoient les fichiers .txt en text/plain sans qu’on le leur dise. Si le vôtre cache les dossiers qui commencent par un point, ajoutez une exception. Dans nginx :
location = /.well-known/security.txt {
default_type text/plain;
charset utf-8;
}La signature est facultative. Avec GnuPG, gpg --clearsign security.txt produit une version signée à publier à la place. Ajoutez une ligne Canonical avant de signer pour que la signature couvre aussi l’adresse.
Cette page lit un hôte, une seule fois. Elle ne peut pas dire si quelqu’un répond à l’adresse de contact, si la politique liée existe, ni si la signature est authentique. Un fichier manquant n’est pas une faille de sécurité et n’abaisse aucune note ici.
Questions fréquentes
L’absence de security.txt est-elle une vulnérabilité ?
Non. Le fichier est une politesse qui facilite le signalement et il ne protège rien à lui seul. Certains scanners automatiques listent son absence comme un constat de faible gravité. Prenez cela comme une suggestion.
Où va exactement security.txt ?
À https://your-domain/.well-known/security.txt, servi en HTTPS comme texte brut. Chaque hôte est distinct, donc un fichier sur example.com ne couvre pas app.example.com.
Publier une adresse de contact attirera-t-il du spam ou de faux rapports de bugs ?
Attendez-vous à quelques rapports automatiques de peu de valeur, souvent pour réclamer une récompense. Une courte page de politique qui dit ce que vous considérez comme dans le périmètre et si vous payez des primes, en filtre la plupart. Faire pointer Contact vers un formulaire web plutôt que vers une boîte aux lettres aide aussi.
Quelle durée donner à la date Expires ?
Moins d’un an d’avance, comme le recommande la RFC. La date est une promesse que les contacts étaient corrects à la dernière révision du fichier, c’est pourquoi elle doit être courte. Programmez un rappel un mois avant son échéance.
Dois-je signer le fichier avec PGP ?
Non. Une signature aide un lecteur à confirmer que le fichier n’a pas été modifié sur un serveur compromis et elle ne fonctionne que si votre clé publique peut être obtenue ailleurs. Beaucoup de fichiers valides ne sont pas signés.
Quelle est la différence entre security.txt et robots.txt ?
Les deux sont des fichiers de texte brut à une adresse connue, lus par des logiciels. robots.txt dit aux robots d’exploration quelles pages laisser tranquilles. security.txt dit aux personnes qui ont trouvé un problème de sécurité comment vous joindre. Aucun des deux n’impose quoi que ce soit.