Partie 5 de la série « Sécurité web dans l'UE : 10 étapes pour une meilleure note »
Pourquoi security.txt
Un chercheur en sécurité trouve une vulnérabilité sur votre site web. Qui contacte-t-il ?
Sans security.txt : Il parcourt votre site, trouve info@, envoie un e-mail. Il arrive au marketing, est supprimé comme spam ou ignoré. La vulnérabilité reste ouverte.
Avec security.txt : Il visite /.well-known/security.txt, trouve le contact sécurité, la clé PGP et la politique de divulgation. Le rapport atteint la bonne équipe immédiatement.
Taux d'adoption dans l'UE : 2,8%. Et pourtant : les sites web avec security.txt obtiennent un score 31% plus élevé en moyenne que ceux qui ne l'ont pas.
La corrélation
| Métrique | AVEC security.txt | SANS | Facteur |
|---|---|---|---|
| Score composite | 55 | 42 | +31% |
| HSTS | 72% | 26% | 2,8x |
| CSP | 47% | 10% | 4,7x |
| Note F | 6% | 44% | 7x moins |
security.txt n'est pas une solution miracle. Mais ceux qui prennent le temps de le configurer se sont généralement occupés de tout le reste aussi.
Comment configurer security.txt
Étape 1 : Créer le fichier
Créez /.well-known/security.txt sur votre serveur web :
Contact: mailto:security@votre-domaine.com
Expires: 2027-04-13T00:00:00.000Z
Preferred-Languages: fr
Champs obligatoires (RFC 9116) :
- Contact: — adresse e-mail ou URL pour les signalements de sécurité
- Expires: — date d'expiration (maximum 1 an dans le futur)
Champs optionnels :
- Encryption: — clé PGP pour les signalements chiffrés
- Acknowledgments: — tableau d'honneur pour les rapporteurs responsables
- Canonical: — URL canonique du fichier
- Policy: — lien vers votre Politique de Divulgation des Vulnérabilités
- Hiring: — lien vers les offres d'emploi en sécurité
Étape 2 : Le rendre accessible
Le fichier doit être accessible à https://votre-domaine.com/.well-known/security.txt. Pour la plupart des configurations :
Nginx :
location = /.well-known/security.txt {
alias /var/www/votre-domaine.com/security.txt;
}
Apache : Placez simplement le fichier dans /.well-known/ à la racine du document.
WordPress : Utilisez le plugin « WP Security.txt » ou placez-le manuellement dans .well-known/ à la racine du site.
Étape 3 : Fournir une clé PGP (recommandé)
Contact: mailto:security@votre-domaine.com
Encryption: https://votre-domaine.com/.well-known/pgp-key.txt
Expires: 2027-04-13T00:00:00.000Z
L'ANSSI et l'ENISA recommandent l'option de chiffrement pour que les chercheurs en sécurité puissent soumettre des détails sensibles de manière protégée.
Adoption par secteur
| Secteur | Adoption | Score moyen avec | Score moyen sans |
|---|---|---|---|
| Banque | 23,9% | 69 | 55 |
| Commerce en ligne | 15,6% | 64 | 53 |
| Éducation | 8,1% | 53 | 42 |
| Tech | 5,3% | 63 | 45 |
| Santé | 2,0% | 58 | 42 |
| Hôtellerie | 1,1% | 51 | 40 |
La banque est en tête — près d'une banque sur quatre a security.txt. L'hôtellerie (hôtels, restaurants) est à 1,1%.
Contexte réglementaire
- NIS2 Art. 21(2)(e) exige explicitement la « gestion et divulgation des vulnérabilités » — security.txt est le mécanisme standardisé pour cela
- CRA Art. 14 — la divulgation coordonnée des vulnérabilités devient obligatoire à partir de décembre 2027 pour les fabricants de produits numériques
- ENISA inscrit security.txt comme bonne pratique pour la divulgation des vulnérabilités
- CERT nationaux à travers l'Europe (ANSSI, CERT-FR, BSI) recommandent ou utilisent security.txt sur leurs propres domaines
Erreurs courantes
1. Oublier Expires. Sans Expires, le fichier n'est pas valide selon le RFC 9116. Définissez-le à 1 an dans le futur et créez un rappel pour le mettre à jour.
2. HTTP au lieu de HTTPS. Le fichier doit être servi en HTTPS — un security.txt non chiffré pourrait être altéré.
3. info@ comme contact. Contact: mailto:info@... arrive au marketing. Configurez une adresse security@ dédiée qui atteint un responsable de la sécurité.
Vérifiez votre security.txt
La semaine prochaine dans la Partie 6 : DKIM — pourquoi seulement 31% des domaines de l'UE signent leurs e-mails.