Un emplacement facile à trouver
Une personne remarque un problème potentiel sur votre site et souhaite le signaler. Devoir chercher entre le service commercial, l'assistance et plusieurs prestataires crée un délai évitable. Un circuit clair permet à cette personne de trouver un destinataire et à votre entreprise de recevoir un signalement exploitable.
Le RFC 9116 décrit security.txt. Pour les services web, le fichier est accessible en HTTPS à l'emplacement /.well-known/security.txt. Les champs Contact et Expires sont obligatoires.
Commencez par un inventaire simple : quels domaines publics appartiennent à votre entreprise, qui les exploite et où les signalements doivent-ils arriver ? Validez les coordonnées publiées avec les personnes qui traiteront effectivement les messages. [1]
Attribuer la boîte à une personne responsable
Désignez une personne responsable et un suppléant. Définissez qui consulte les messages, qui évalue les questions techniques et qui prend le relais en cas d'absence. Si plusieurs prestataires interviennent, précisez le service dont chacun est responsable.
Organisez un test de livraison inoffensif, explicitement convenu, avec un objet facilement identifiable. Ne vérifiez pas seulement que l'envoi réussit : le message arrive-t-il dans la bonne boîte, entre-t-il dans le circuit de traitement et son destinataire peut-il répondre ? L'accessibilité du fichier ne suffit pas à le démontrer.
Un ticket partagé ou une référence interne peut suffire. Notez l'heure de réception, le service concerné, la personne responsable et la prochaine action. Évitez de transmettre des informations sensibles à des listes de diffusion trop larges.
Le circuit de signalement en un regard
L'illustration distingue quatre tâches. Le fichier publié indique le contact. Le point d'entrée reçoit le signalement. Une personne désignée vérifie son rapport avec les systèmes de l'entreprise. Une réponse permet de poursuivre l'échange.
Cette organisation convient aussi à une petite équipe. Chaque passage de relais doit être explicite : qui détient le dossier, quelle question reste ouverte et quand la prochaine action sera-t-elle examinée ? Si le service est exploité par un prestataire, prévoyez également cette transmission.
/.well-known/security.txt
Accessible publiquement
Contact:Adresse ou formulaire de signalement
Expires:Fin de validité des coordonnées
Réception
Enregistrer le signalement et en accuser réception.
Responsabilité
Identifier le service concerné et la personne responsable.
Réponse
Consigner la prochaine étape et le canal de réponse.
Le fichier rend le canal de signalement visible. L'attribution et le suivi s'organisent dans l'entreprise.
Accompagner le contact de règles claires
Publier une adresse de contact ne constitue pas, à lui seul, une commande de test de sécurité. Distinguez le signalement d'une observation de l'autorisation de mener des tests supplémentaires.
Le NCSC recommande une politique claire de divulgation : canaux de contact, informations attendues, réponse prévue et limites des investigations autorisées.
Pour un premier message, nous recommandons l'adresse concernée, une brève description et la date de l'observation. Des mots de passe ou de vastes ensembles de données personnelles ne sont pas nécessaires à ce stade. Si d'autres preuves sont requises, convenez d'un mode de transmission adapté. N'annoncez que des délais de réponse que votre équipe peut tenir. [2]
Revoir le contact à chaque changement
Traitez ce contact comme une coordonnée opérationnelle. Ajoutez sa vérification aux listes de contrôle des migrations de domaines, des changements de prestataires et des départs de personnel. Planifiez un contrôle avant l'expiration des informations.
Une vérification régulière peut rester simple : consulter le fichier public, comparer les coordonnées aux responsabilités internes et contrôler le circuit convenu. Consignez le résultat et la date. Le fichier devient ainsi un canal entretenu pour recevoir des signalements utiles.
Vérifier les champs et la réponse HTTP
Pour un service web, le fichier doit être accessible en HTTPS à /.well-known/security.txt, en texte UTF-8 avec le type text/plain. Une page d’erreur HTML renvoyant le statut 200 n’est pas un fichier security.txt valide. Vérifiez le corps et les en-têtes de la réponse.
Le périmètre est précis : un fichier sur example.com ne couvre pas automatiquement ses sous-domaines. Répertoriez chaque hôte visé. Les champs ci-dessous sont une sélection, pas une vérification complète de conformité à la RFC 9116. [1]
Faites défiler le tableau horizontalement.
| Champ | Exigence | Contrôle pratique |
|---|---|---|
| Contact | Obligatoire ; au moins une URI de contact. | Utiliser mailto: pour un courriel ; convenir d’un test de réception et le vérifier. |
| Expires | Obligatoire ; un seul horodatage RFC 3339. | Vérifier la validité et prévoir le renouvellement ; moins d’un an dans le futur est recommandé. |
| Preferred-Languages | Facultatif ; langues réellement prises en charge. | Ne citer que les langues dans lesquelles les signalements peuvent être traités. |
| Canonical | Facultatif ; adresse HTTPS prévue du fichier. | La comparer à l’adresse effectivement consultée. |
| Policy | Facultatif ; lien vers la politique de divulgation. | Préciser le canal, le périmètre autorisé et le suivi. |
Consigner le contrôle et désigner un responsable
La checklist relie le fichier public au circuit de traitement interne. Utilisez une copie par domaine, saisissez les résultats observés et planifiez une nouvelle revue. Ce n’est pas un scanner automatique et elle ne certifie pas, à elle seule, la sécurité de la configuration.