Je viens de publier une politique de divulgation de vulnérabilités sur le site web de Certi360. Avec le fichier qui va avec, /.well-known/security.txt.

Pendant que je le rédigeais, une question m’est restée en tête. Ce fichier a été pensé pour des chercheurs qui trouvent une faille et veulent vous prévenir. Les robots qui balaient votre site web à 3 h du matin, eux, ne vous écriront jamais.

Alors, ça sert encore à quelque chose? Oui, à condition de comprendre ce que ce fichier est et ce qu’il n’est pas.

Rappel rapide

security.txt est un simple fichier texte publié à une adresse fixe, https://votredomaine.com/.well-known/security.txt. Il dit à quelqu’un qui a trouvé un problème de sécurité qui contacter et comment.

L’idée vient d’Edwin Foudil, un chercheur en sécurité, qui a soumis un premier brouillon à l’IETF (l’organisme qui publie les standards d’Internet) en septembre 2017. Le principe était calqué sur robots.txt : un emplacement prévisible, lisible par un humain comme par une machine. Le texte est devenu un standard officiel, la RFC 9116, en avril 2022, cosigné avec Yakov Shafranovich.

Le problème qu’il réglait était réel. Un chercheur trouve une faille, cherche un contact et tombe sur le formulaire « Nous joindre ». Son courriel se perd et la faille reste ouverte.

Ce que le fichier contient

Deux champs sont obligatoires :

  • Contact, une adresse courriel, un numéro de téléphone ou une page web.
  • Expires, une date d’expiration. La RFC recommande moins d’un an.

Les autres sont optionnels, comme Encryption (lien vers votre clé publique), Policy (votre politique de divulgation), Acknowledgments (la page de remerciements), Preferred-Languages, Canonical et Hiring.

Le fichier doit être servi en HTTPS, en texte brut. Idéalement, il est signé avec une clé PGP (le standard de chiffrement et de signature des courriels). Sans signature, un attaquant qui a compromis votre site peut remplacer votre adresse par la sienne et recevoir les signalements à votre place.

Un exemple minimal :

Contact: mailto:security@votredomaine.com
Expires: 2027-06-30T23:59:59Z
Encryption: https://votredomaine.com/cle-pgp.txt
Policy: https://votredomaine.com/divulgation/
Preferred-Languages: fr, en
Canonical: https://votredomaine.com/.well-known/security.txt

Ce que le fichier n’est pas

Ce n’est pas une mesure de sécurité. Il ne bloque rien et ne détecte rien.

Ce n’est pas une autorisation de tester. La RFC le dit noir sur blanc : la présence du fichier ne donne aucune permission de sonder vos systèmes. Son absence n’en retire aucune non plus.

Et ce n’est pas un programme de primes. Vous n’avez rien à payer à personne.

L’autre changement, le bruit

Le robot qui trouve votre extension WordPress vulnérable ne vous écrira pas. Il va passer à l’action. security.txt ne change rien à ça. Vos mises à jour, votre inventaire et vos propres tests, oui.

Le fichier sert à l’autre personne, celle de bonne foi qui tombe sur un problème et veut vous le dire. Un chercheur, un client, un étudiant, un consultant d’une autre firme. Sans canal clair, cette personne abandonne. Ou publie.

Ce canal a un coût. La RFC elle-même prévient qu’une adresse de contact publique attire du pourriel et des rapports automatisés.

En 2026, c’est devenu un problème majeur. Le projet curl a fermé son programme de primes à la fin de janvier, noyé sous des rapports générés par IA. Le 1er octobre, Google a suspendu les soumissions de son programme de primes pour les logiciels libres, au moins jusqu’au premier trimestre 2027, pour la même raison.

Une PME n’en recevra pas des milliers. Pourtant, chaque faux rapport prend du temps à quelqu’un qui en a déjà peu.

S’ajoutent les « beg bounties », des courriels non sollicités, souvent issus d’un scan automatique, qui réclament un paiement pour une « faille critique ». Sophos a documenté des demandes de 150 à 2 000 dollars américains par faille. La plus fréquente est l’absence d’un enregistrement SPF ou DMARC (deux réglages qui protègent votre domaine contre l’usurpation de courriel). Ce n’est pas une vulnérabilité de votre site web. C’est une question de configuration de votre courriel.

Quand l’utiliser

Vous avez un site web, une application ou un portail client exposé sur Internet. Quelqu’un va lire la boîte de réception chaque semaine. Vous pouvez trier, répondre et corriger dans un délai raisonnable.

Quand ne pas l’utiliser

Personne ne surveillera l’adresse. Un fichier qui pointe vers une boîte morte est pire que pas de fichier. La RFC le reconnaît : une information périmée fait perdre des signalements.

Vous n’êtes pas prêt à renouveler la date d’expiration. Un fichier expiré dit au monde que personne n’est aux commandes.

Vous voulez y inscrire l’adresse personnelle d’un employé. Utilisez un alias. Les employés partent, les alias restent.

En pratique

  1. Créez un alias security@ qui aboutit chez deux personnes, pas une.
  2. Rédigez une politique courte qui couvre la portée, les exclusions, le délai demandé avant divulgation publique et l’engagement de ne pas intenter de poursuite ni de déposer de plainte si la personne respecte la politique.
  3. Fixez une date d’expiration à moins d’un an et un rappel au calendrier un mois avant.
  4. Signez le fichier avec votre clé PGP, sur votre poste ou dans votre client de courriel chiffré, jamais dans un site de signature en ligne. Publiez ensuite la clé publique sur keys.openpgp.org et confirmez l’adresse courriel. Un chercheur aura une deuxième source pour la vérifier, hors de votre site.
  5. Publiez un fichier par domaine exposé. Un sous-domaine applicatif mérite le sien.
  6. Préparez deux réponses types, l’accusé de réception et « ceci n’est pas une vulnérabilité ».
  7. Ne payez jamais un beg bounty. Validez le rapport vous-même ou avec votre fournisseur MSP, puis corrigez si c’est réel.

À quoi vous attendre

Peu de rapports utiles. Beaucoup de bruit. De temps en temps, un vrai signalement qui vous évite un incident.

Un seul rapport valide reçu avant qu’un attaquant ne trouve la même faille vaut le temps passé à trier le pourriel.

Mesurez-le. Combien de rapports, combien de valides, combien de temps pour corriger. Après un an, vous allez savoir si votre canal fonctionne.

Chez Certi360

Je l’ai mis en place. Le fichier est ici : /.well-known/security.txt. Il pointe vers security@certi360.com, notre clé PGP, la politique de divulgation et les remerciements.

Environ 90 jours avant une divulgation publique. Si vous respectez cette politique, nous n’intenterons aucune poursuite et ne déposerons aucune plainte en lien avec le signalement. Pas de primes. Une reconnaissance publique pour ceux qui le souhaitent.

Je le recommande à mes clients. Difficile d’exiger des autres ce qu’on ne fait pas soi-même.

Vous voulez un regard sur le vôtre? Parlons-en.

Références