Vérificateur Security.txt

Validez votre fichier security.txt par rapport à RFC 9116. Vérifiez les champs obligatoires (Contact, Expires), les champs optionnels (Encryption, Policy, Canonical), l'état d'expiration et l'hébergement HTTPS. Obtenez un score de santé et des recommandations exploitables.

Comment utiliser Vérificateur Security.txt

  1. 1Entrez un nom de domaine (par exemple, example.com).
  2. 2L'outil récupère /.well-known/security.txt et /security.txt.
  3. 3Les champs sont analysés et validés par rapport aux exigences RFC 9116.
  4. 4Consultez le score de santé, tous les problèmes trouvés et les recommandations.
ZenovayAnalytics

Voyez qui est sur votre site en ce moment.

  • Suivi des visiteurs en temps réel
  • Vie privée d'abord, sans bandeau cookies
  • Installé en deux minutes
Découvrir Zenovay

Questions fréquemment posées

Qu'est-ce que security.txt et pourquoi est-il important ?
security.txt est un fichier texte placé à /.well-known/security.txt sur un site web qui indique aux chercheurs en sécurité comment divulguer les vulnérabilités de manière responsable. Standardisé dans la RFC 9116, il fournit des coordonnées, une politique de divulgation, des clés de chiffrement et une date d'expiration. Sans lui, les chercheurs peuvent ne pas savoir comment contacter votre équipe de sécurité.
Quels champs sont requis dans security.txt ?
La RFC 9116 exige deux champs : (1) Contact : au moins une méthode de contact (URI mailto:, https:, ou tel:), et (2) Expires : une date/heure ISO 8601 indiquant quand ce fichier doit être considéré comme périmé. Tous les autres champs sont optionnels mais fortement recommandés : Encryption, Policy, Canonical, Preferred-Languages, Acknowledgments, Hiring.
Où security.txt doit-il être placé ?
L'emplacement préféré selon la RFC 9116 est /.well-known/security.txt (ex. https://exemple.com/.well-known/security.txt). L'emplacement legacy /security.txt est également pris en charge pour la rétrocompatibilité. Le fichier doit être servi en HTTPS.
Quelle devrait être la durée de validité de security.txt ?
La RFC 9116 recommande de définir le champ Expires à un an au maximum dans le futur. Une validité plus courte (90-180 jours) force une révision régulière et garantit que les coordonnées restent à jour. Les fichiers security.txt expirés sont traités comme si aucun fichier n'existait.
security.txt devrait-il être signé PGP ?
La signature PGP est optionnelle mais recommandée pour les environnements à haute sécurité. Un security.txt signé permet aux chercheurs de vérifier que le fichier n'a pas été altéré — un attaquant qui compromet votre serveur web pourrait autrement remplacer votre security.txt par une adresse de contact différente.