Ce qu'est réellement security.txt
security.txt est un simple fichier texte, défini dans la RFC 9116, qui indique à quiconque trouve une vulnérabilité de sécurité sur votre site exactement comment la signaler. Il se trouve à un emplacement prévisible — /.well-known/security.txt — afin que les chercheurs en sécurité et les scanners automatisés n'aient pas à fouiller votre page de contact ou à deviner une adresse e-mail.
Un exemple minimal ressemble à ceci :
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: fr
C'est tout le format : un petit ensemble de champs en texte brut, chacun sur sa propre ligne. Pas de JSON, pas de XML, rien de compliqué.
Pourquoi c'est plus qu'un simple « ce serait bien »
Sans fichier security.txt, un chercheur qui trouve une vulnérabilité sur votre site WordPress a des options limitées : fouiller votre formulaire de contact, deviner une adresse e-mail, ou — s'il ne trouve rien de raisonnable — publier la vulnérabilité publiquement sans vous donner la chance de la corriger d'abord. Aucun de ces résultats n'est bon pour vous.
Il y a aussi un angle réglementaire. Le Cyber Resilience Act de l'UE, qui s'applique aux produits à éléments numériques vendus dans l'UE, exige des fabricants un processus documenté de gestion et de divulgation des vulnérabilités. security.txt ne constitue pas toute l'exigence de conformité, mais c'est la manière standard et attendue de rendre ce processus repérable publiquement. Si votre site WordPress sert des utilisateurs de l'UE ou vend des produits numériques, en avoir un est une petite étape peu coûteuse vers cette attente plus large.
Quels champs appartiennent réellement au fichier
La RFC définit plusieurs champs, dont tous ne sont pas requis. Voici ce que fait chacun :
Contact (requis, au moins un) : Comment vous joindre. Peut être un e-mail (mailto:), une URL vers un formulaire de signalement, ou les deux. Vous pouvez lister plusieurs lignes Contact si vous avez plus d'un canal de signalement.
Expires (requis) : Un horodatage ISO 8601. Cela vous oblige à revisiter et reconfirmer le fichier périodiquement — un security.txt vieux de plusieurs années avec des coordonnées obsolètes est sans doute pire que de n'en pas avoir du tout. Définissez-le à quelque chose de réaliste, comme dans un an, et mettez-le à jour à son expiration.
Encryption (optionnel) : Un lien vers une clé PGP si vous voulez que les chercheurs chiffrent les rapports contenant des détails sensibles avant de les envoyer.
Acknowledgments (optionnel) : Un lien vers une page créditant les chercheurs ayant signalé des problèmes de manière responsable — une petite incitation que certains chercheurs recherchent spécifiquement avant de décider de signaler plutôt que de divulguer publiquement.
Preferred-Languages (optionnel) : Dans quelles langues vous pouvez lire les rapports.
Canonical (optionnel) : L'URL faisant autorité du fichier lui-même, utile si votre site est accessible via plusieurs domaines.
Policy (optionnel) : Un lien vers votre politique complète de divulgation des vulnérabilités — le document détaillé décrivant le périmètre, les délais de réponse attendus, et ce que les chercheurs peuvent attendre de vous.
Ajouter security.txt à WordPress
Comme la structure « Réglages → Permaliens » de WordPress gère la plupart des URL via PHP, faire en sorte qu'un fichier statique se trouve à /.well-known/security.txt nécessite l'une de ces deux approches :
Option A — Téléverser le fichier directement via FTP/gestionnaire de fichiers. Créez un fichier nommé security.txt avec le contenu ci-dessus, et téléversez-le dans le répertoire .well-known à la racine web de votre site (créez le répertoire s'il n'existe pas). Cela fonctionne sur pratiquement n'importe quel hébergeur et ne dépend pas du tout de WordPress, ce qui est en réalité un avantage — cela continuera de fonctionner même si vous changez de thème ou d'extensions.
Option B — Utiliser une extension qui le gère pour vous. Maintenir manuellement un fichier statique signifie se souvenir de mettre à jour le champ Expires chaque année et de synchroniser les coordonnées de contact si elles changent. Erdo CRA Compliance génère et sert un fichier security.txt dans le cadre de son analyse de conformité UE plus large, en même temps que les autres documents (politique de divulgation des vulnérabilités, SBOM) attendus par le Cyber Resilience Act — il est donc maintenu en un seul endroit plutôt que comme un fichier statique oublié d'il y a trois ans.
Erreurs courantes
Quelques points à vérifier une fois le fichier ajouté :
- Oublier de mettre à jour Expires. Un security.txt expiré signale plus de négligence que son absence. Programmez un rappel, ou utilisez un outil qui gère cela pour vous.
- Utiliser une adresse de contact que personne ne surveille. Si security@votredomaine.com aboutit dans une boîte que personne ne consulte, vous avez résolu le problème de repérabilité et créé une nouvelle impasse.
- Le placer uniquement à la racine du domaine. /.well-known/security.txt est l'emplacement standard actuel. Un /security.txt au niveau racine est autorisé comme solution de repli pour les anciens robots, mais ne comptez pas uniquement sur lui.
- Le traiter comme toute l'histoire de la conformité. security.txt rend votre canal de divulgation repérable ; cela ne remplace pas d'avoir un véritable processus de triage quand un signalement arrive.
En résumé
security.txt est une correction de cinq minutes avec un bénéfice disproportionné : il transforme « j'ai trouvé un bug sur votre site, et maintenant ? » d'une impasse en un processus documenté. Que vous l'ajoutiez manuellement comme fichier statique ou que vous laissiez un outil de conformité le maintenir avec vos autres documents UE, c'est l'une des pratiques de sécurité les moins coûteuses et les plus rentables qu'un site WordPress puisse adopter.