Outils GitHub Pages

Gratuit Générateur & validateur security.txt

Générez et validez des fichiers security.txt selon la RFC 9116 avec guide d'hébergement.

Chargement de l'outil...

Qu'est-ce que Générateur & validateur security.txt ?

security.txt est un fichier texte simple publie a /.well-known/security.txt qui indique aux chercheurs en securite comment vous contacter a propos de vulnerabilites. Il est defini par la RFC 9116 et soutenu par Google, GitHub et les principales plateformes de divulgation de vulnerabilites. Le fichier contient un champ Contact (URL ou e-mail), une date Expires, et des champs facultatifs comme Canonical, Encryption, Policy, Acknowledgments et Hiring.

Réponse rapide

security.txt est un fichier place a /.well-known/security.txt qui indique aux chercheurs en securite comment vous signaler des vulnerabilites. Incluez au minimum un champ Contact (URL ou e-mail) et une date Expires. Renouvelez le fichier avant son expiration pour maintenir votre canal de divulgation actif.

Last updated: 2026-05-28

Limites

  • security.txt est un standard propose (RFC 9116), pas une recommandation W3C. Certaines organisations ne le connaissent pas encore, et l'adoption par les scanners automatiques varie selon les regions et les secteurs.
  • Le fichier doit etre servi via HTTPS sans redirections. Certaines plateformes d'hebergement statique (dont GitHub Pages) peuvent rediriger les chemins /.well-known/ ou les servir avec des types de contenu inattendus.
  • security.txt seul ne cree pas de programme de divulgation de vulnerabilites ou de bug bounty. Il indique seulement aux chercheurs ou signaler — vous avez toujours besoin d'un processus interne pour traiter les rapports entrants.

Sources:MDN Web Docs · W3C Specifications · jquery.app on GitHub

Comment utiliser cet outil

  1. En mode Generation : remplissez votre URL ou e-mail de contact, definissez une date d'expiration et ajoutez les champs facultatifs.
  2. En mode Validation : collez un fichier security.txt existant pour le verifier par rapport a la specification RFC 9116.
  3. Deployez le fichier vers /.well-known/security.txt sur votre domaine et servez-le via HTTPS.

A quoi il sert

  • Creer un contact de divulgation de vulnerabilite pour le site d'un projet open-source.
  • Valider un security.txt existant avant de le deployer sur un domaine de production.
  • S'assurer que la date Expires n'est pas passee et que le champ Contact utilise un format d'URL ou d'e-mail valide.

Cas d'usage

Exemples concrets

Exemple

Page de contact securite pour un site SaaS

Une entreprise SaaS cree un security.txt avec un e-mail dedie security@ et un lien vers sa page de politique de divulgation des vulnerabilites. Le fichier est place dans le repertoire /.well-known/ et servi via HTTPS.

Exemple

Site statique open-source

Un site d'outil open-source heberge sur GitHub Pages ajoute un security.txt avec un lien vers sa page GitHub Security Advisories. Le fichier inclut Preferred-Languages et une cle Encryption pour les rapports chiffres en PGP.

Erreurs frequentes

  • Placer security.txt a la racine du site au lieu de /.well-known/security.txt — le chemin /.well-known/ est requis par la RFC 9116.
  • Laisser la date Expires passer sans renouvellement — les scanners automatiques ignorent les fichiers security.txt expires.
  • Servir le fichier via HTTP au lieu de HTTPS — le fichier doit etre accessible via HTTPS sans redirections.

Vérification

  1. Visitez https://votredomaine.com/.well-known/security.txt dans un navigateur et confirmez qu'il se charge directement via HTTPS sans redirections.
  2. Utilisez curl -I https://votredomaine.com/.well-known/security.txt pour verifier que le Content-Type est text/plain et que le statut de reponse est 200.

FAQ

Questions sur Générateur & validateur security.txt

Ou exactement dois-je placer le fichier security.txt ?

Placez-le a /.well-known/security.txt — l'URL complete doit etre https://votredomaine.com/.well-known/security.txt. Pour GitHub Pages, creez un repertoire .well-known dans la racine de votre site publie et placez security.txt a l'interieur. Le fichier doit etre servi directement, sans redirection.

A quelle frequence dois-je renouveler la date Expires ?

La RFC 9116 recommande de definir la date Expires a 12 mois maximum a partir de la date courante. Configurez un rappel calendaire pour la renouveler avant expiration. Les scanners automatiques et les plateformes de bug bounty ignorent les fichiers security.txt expires, ce qui annule leur interet.

Puis-je avoir plusieurs champs Contact ?

Oui. La RFC 9116 autorise plusieurs champs Contact. Cela est utile lorsque vous avez des contacts securite et abus separes, ou lorsque vous souhaitez lister a la fois une URL de formulaire web et une adresse e-mail de secours. Listez les contacts par ordre de preference.

Outils lies

Autres outils outils github pages

A essayer aussi

A essayer aussi