Rédigez des signalements d'abus pour registraires, hébergeurs et CDN, en e-mail et en JSON.
Nouveau
Générateur de security.txt
Exécution locale
L'outil lui-même est en anglais ; cette page vous l'explique dans votre langue.
Utilisez Générateur de security.txt
Fonctionnalités
Créez un fichier security.txt pour que les chercheurs et les personnes qui signalent du phishing imitant votre marque sachent comment vous joindre. Enregistrez le résultat sous /.well-known/security.txt.
Tout se passe entièrement dans votre navigateur : aucune des données que vous saisissez n'est transmise.
Comment utiliser Générateur de security.txt
- Saisissez un contact. Dans le champ « Contact », indiquez les coordonnées de votre équipe de sécurité, une par ligne : mailto:security@example.com, l'adresse https:// d'un formulaire de signalement ou un numéro de téléphone. Si vous indiquez uniquement une adresse e-mail, « mailto: » sera ajouté automatiquement.
- Fixez la date d'expiration. Choisissez une date dans Expires. Par défaut, elle est fixée à un an à partir d'aujourd'hui ; la RFC 9116 recommande moins d'un an, choisissez donc une date plus proche.
- Ajoutez les champs facultatifs. Remplissez Preferred-Languages (en par défaut), Canonical, Policy, Encryption, Acknowledgments et Hiring si vous en disposez. Les champs vides sont omis du fichier.
- Générez et copiez. Appuyez sur Generate et lisez le résultat dans la zone de sortie. Vérifiez encore une fois chaque adresse, car l'outil les recopie telles que saisies, puis appuyez sur Copy.
- Publiez et renouvelez. Enregistrez le texte sous /.well-known/security.txt sur votre site en HTTPS, signez-le avec gpg --clearsign si vous le souhaitez, et notez une date pour le renouveler avant son expiration.
Exemple
Fichier minimal
mailto:security@example.comContact: mailto:security@example.com
Expires: 2027-10-20T23:59:59.000Z
Preferred-Languages: enGénère les champs « Contact » : mailto:security@example.com, une date d'expiration fixée un an à l'avance à 23 h 59 min 59 s (Z) et « Preferred-Languages » : en, soit les deux champs obligatoires ainsi qu'une indication de langue, avec un rappel indiquant que la norme RFC 9116 recommande une date d'expiration inférieure à un an.
Ce qu'il vérifie
| Signal | Ce que cela signifie |
|---|---|
| Contact: | Une ligne par contact, dans l'ordre où vous les avez saisis. Chacun doit être un URI de type « mailto: », « https:// » ou « tel: », conformément à la norme RFC 9116 ; les liens de type « http:// » et les valeurs mal formées génèrent une erreur au lieu d'un fichier. |
| Expires: | La date choisie à 23:59:59 UTC, écrite avec les millisecondes, par exemple 2027-03-31T23:59:59.000Z. Si vous videz le champ de date, Generate ne produit plus de nouveau fichier. |
| Preferred-Languages: | en par défaut. Utilisez des codes de langue séparés par des virgules, comme en, de, ou videz le champ pour omettre la ligne. |
| Canonical: | L'adresse https:// complète où se trouve ce fichier, pour qu'une copie servie ailleurs puisse être reconnue. |
| Encryption: | Un lien vers votre clé publique OpenPGP, pour que les personnes qui signalent puissent chiffrer les détails sensibles. |
| Policy, Acknowledgments, Hiring | Des liens vers votre politique de divulgation, une page de remerciements pour les personnes qui signalent, et vos offres d'emploi en sécurité. Tous facultatifs, et l'outil ne vérifie pas que les liens fonctionnent. |
| Une adresse de rôle dans Contact | Utilisez une adresse ou un formulaire surveillé par une équipe, comme security@ suivi de votre domaine, et non la boîte d'une seule personne, pour que les signalements arrivent toujours quand les gens changent de poste. |
| Error: Contact is required | S'affiche lorsque le champ « Contact » est vide. Toute erreur remplace le message affiché par une note indiquant qu'aucun résultat n'a été généré tant que les champs n'ont pas été corrigés. |
D'autres exemples
Formulaire web avec langues et politique
Contact https://example.org/report-security, Expires 2027-03-31, Preferred-Languages en, de, Canonical https://example.org/.well-known/security.txt, Policy https://example.org/security-policyCinq lignes dans cet ordre : Contact: https://example.org/report-security, Expires: 2027-03-31T23:59:59.000Z, Preferred-Languages: en, de, Canonical: https://example.org/.well-known/security.txt, Policy: https://example.org/security-policy.
Contact e-mail avec une clé, sans langue
Contact mailto:abuse@example.net, Expires 2027-06-30, Preferred-Languages cleared, Encryption https://example.net/pgp-key.txtTrois lignes : Contact: mailto:abuse@example.net, Expires: 2027-06-30T23:59:59.000Z et Encryption: https://example.net/pgp-key.txt.
Contact laissé vide
All fields filled except ContactErreur : le champ « Contact » est obligatoire, et un message indique qu'aucune donnée n'a été générée. Les autres champs conservent leurs valeurs ; veuillez donc remplir le champ « Contact » et cliquer à nouveau sur « Générer ».
FAQ
Quels champs sont obligatoires ?
La RFC 9116 exige au moins un champ « Contact » et exactement un champ « Expires » ; les autres sont facultatifs. Chaque ligne « Contact » doit être un URI de type « mailto: », « https:// » ou « tel: » (une adresse e-mail seule se voit ajouter « mailto: »), le champ « Expires » doit indiquer une date future, et la fonction « Generate » affiche une erreur au lieu d'un fichier si l'un de ces champs est manquant ou invalide.
Quelle valeur donner à Expires ?
La date par défaut est fixée à un an à compter d'aujourd'hui, alors que la RFC 9116 recommande une durée inférieure à un an ; choisissez donc une date antérieure pour respecter cette recommandation ; la page vous le rappelle lorsque la date se situe à plus d'un an dans le futur. Renouvelez le fichier avant cette date, car la RFC précise qu'un fichier security.txt périmé doit être considéré comme obsolète.
Téléverse-t-il ou signe-t-il quelque chose ?
Non. Le fichier est assemblé dans votre navigateur et rien n'est envoyé nulle part. Il n'est pas signé ; la RFC 9116 recommande une signature OpenPGP en clair (cleartext), que vous pouvez ajouter avec gpg --clearsign avant la publication.
Puis-je indiquer plusieurs contacts ?
Oui. La norme RFC 9116 autorise plusieurs lignes de contact, qui sont lues par ordre de préférence. Saisissez un contact par ligne dans le champ « Contact » ; les doublons ne sont enregistrés qu'une seule fois.
Où le fichier doit-il se trouver exactement ?
À l'adresse https://your-domain/.well-known/security.txt, servi en HTTPS sous forme de texte brut. Une copie ou une redirection à /security.txt est facultative.
Un seul fichier couvre-t-il mes sous-domaines ?
Non. La RFC 9116 indique qu'un security.txt ne s'applique qu'à l'hôte depuis lequel il a été récupéré, ni à ses sous-domaines ni à son domaine parent. Publiez une copie sur chaque hôte où l'on pourrait la chercher, comme www et shop.
En quoi security.txt aide-t-il contre le phishing qui copie ma marque ?
Les personnes qui trouvent un site sosie ou un faux e-mail à votre nom veulent souvent vous prévenir. Une ligne Contact fonctionnelle fait parvenir ce signalement à votre équipe de sécurité plutôt qu'à une file de support générale, ce qui vous permet d'agir plus tôt contre le domaine sosie.