Publier security.txt pour un site événementiel

Délimiter domaines et responsables

Télécharger exemple et feuille de routage (Markdown, anglais)

Recensez domaines publics et exploitants. Selon RFC 9116, le fichier concerne le domaine qui le sert, pas automatiquement ses sous-domaines. Ne revendiquez pas les systèmes d’un prestataire de billetterie; prévoyez une transmission claire.[1][2][3]

Choisir un canal suivi

Utilisez une boîte sécurité ou un formulaire sûr avec responsable et suppléant. Séparez-le de l’aide aux participants. Prévoyez accusé, tri privé et escalade. Ne demandez pas mots de passe, listes complètes de participants ou cartes par e-mail.[1][2][3]

Publier le minimum valide

Contact et Expires sont obligatoires. Contact doit être une URI mailto: ou HTTPS, pas une simple adresse. Servez /.well-known/security.txt via HTTPS en text/plain UTF-8. Le RFC recommande une échéance à moins d’un an. Si Canonical figure, il doit correspondre à l’URL réellement servie.[1][2][3]

Distinguer contact et politique

Policy peut pointer vers une vraie politique; le fichier seul n’accorde ni autorisation de test, ni protection juridique, ni prime, ni délai garanti. Faites approuver ces engagements. Le NCSC présente canal, politique et fichier comme éléments liés.[1][2][3]

Tester fichier et réception

Ouvrez l’URL publique sans connexion. Vérifiez contenu lisible, contact et échéance valides. Envoyez un test interne inoffensif et confirmez sa réception. Répétez après changement de DNS, hébergement ou équipe et avant expiration.[1][2][3]

Orienter sans confondre avec un incident

Consignez domaine, heure, canal, responsable et suite; gardez le signalement privé. Une vulnérabilité n’est pas une intrusion confirmée. En cas d’abus actif ou de données exposées, suivez le plan d’incident et les conseils locaux adaptés.[1][2][3]