Comment bloquer readme.html et license.txt dans WordPress

Ouvrez n'importe quel site WordPress dans le monde et ajoutez /readme.html à l'URL. Dans la grande majorité des cas, vous obtiendrez une page HTML propre qui annonce fièrement la version exacte de WordPress dans le titre. Même histoire pour /license.txt, qui est un peu moins spécifique mais confirme tout de même que le site fonctionne avec WordPress et donne une idée approximative de l'ancienneté de l'installation.

Les deux fichiers sont livrés avec le cœur de WordPress. Ils sont restaurés à chaque mise à jour. Aucun des deux n'est nécessaire au fonctionnement du site. Le seul public qu'ils servent réellement, ce sont les scanners automatisés qui empreintent les sites par version du cœur afin de croiser le résultat avec une liste de vulnérabilités connues. Ce guide explique pourquoi cela compte en pratique et comment bloquer proprement les fichiers sur Apache, sur nginx et sur l'hébergement mutualisé où vous avez moins de contrôle direct.

Pourquoi est-ce important que readme.html soit accessible ?

La réponse honnête : en soi, pas tellement. Connaître la version WordPress d'un site n'est pas une vulnérabilité. La version du cœur de WordPress n'est pas un secret, et un attaquant déterminé peut généralement la deviner de toute façon, par exemple à partir des balises meta generator, du paramètre de version sur les scripts et styles mis en file d'attente, ou de la structure de la réponse de l'API REST.

Ce qui change la donne, c'est la manière dont l'exploitation fonctionne aujourd'hui à grande échelle. Les scanners de masse ne choisissent pas une cible avant de chercher des bugs. Ils choisissent une CVE, construisent une liste de tous les domaines sur Internet exécutant une version affectée et tirent l'exploit sur la liste entière. La façon la moins coûteuse de construire cette liste est de récupérer readme.html sur des millions de domaines en parallèle et d'analyser la version dans le titre. Tout ce qui rend votre site invisible à cette étape de filtrage vous retire de la liste des candidats avant même que l'exploit ne s'exécute.

Donc supprimer readme.html ne rend pas le site sécurisé. Cela retire l'une des empreintes les moins coûteuses, ce qui en pratique signifie que vous cessez d'apparaître dans les listes automatisées de « sites WordPress exécutant la version X.Y.Z ». Cela vaut quelques minutes de travail, même si ce n'est pas le durcissement de sécurité le plus critique que vous puissiez faire.

Qu'en est-il de license.txt et des autres fichiers cœur ?

Même famille de fichier, légèrement moins intéressante :

• license.txt contient le texte de la licence GPL. Il ne comporte pas de numéro de version, mais sa présence à la racine de WordPress est un signal fort que le site fonctionne avec WordPress.
• wp-config-sample.php est livré avec chaque installation. Il ne contient pas d'identifiants, mais révèle que personne n'a fait le ménage après l'installation.
• readme.html est celui qui pose le problème de divulgation de version.

La règle de blocage ci-dessous couvre les trois en une seule fois. Il n'y a aucune bonne raison de laisser l'un d'entre eux accessible publiquement.

Option 1 : bloquer via .htaccess (Apache et LiteSpeed)

Si votre hébergeur fonctionne sous Apache ou LiteSpeed (ce qui couvre la plupart des hébergeurs mutualisés sur le marché germanophone : All Inkl, IONOS, Strato, DomainFactory, Hostinger et la plupart des revendeurs), vous pouvez ajouter le bloc suivant au fichier .htaccess à la racine de votre WordPress :

<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php)$">
  Require all denied
</FilesMatch>

Le snippet utilise la syntaxe Apache 2.4, ce que tous les hébergeurs utilisent depuis des années. Si vous êtes coincé sur Apache 2.2 (extrêmement rare en 2026, mais possible sur de l'hébergement existant), utilisez l'ancienne syntaxe :

<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php)$">
  Order allow,deny
  Deny from all
</FilesMatch>

Placez le bloc au-dessus du marqueur # BEGIN WordPress. Tout ce qui se trouve entre # BEGIN WordPress et # END WordPress est géré par WordPress lui-même et est réécrit lorsque les permaliens changent ou lors des mises à jour du cœur. Tout ce qui est en dehors de ces marqueurs est laissé tel quel.

Après avoir enregistré le fichier, ouvrez https://votredomaine.com/readme.html dans une fenêtre de navigation privée. Vous devriez obtenir un 403 Forbidden. Idem pour /license.txt. Si vous voyez encore le contenu du fichier, votre hébergeur ignore soit complètement .htaccess (rare sur Apache, normal sur nginx) soit a configuré AllowOverride avec une valeur qui retire les directives FilesMatch. Passez à l'option 3.

Option 2 : bloquer via nginx

Sur nginx, il n'y a pas de .htaccess. Si vous gérez votre propre serveur (un VPS chez Hetzner, Netcup, DigitalOcean, ou un hébergeur nginx managé où vous contrôlez la configuration), ajoutez ce qui suit à l'intérieur du bloc server de votre site :

location ~* ^/(readme\.html|license\.txt|wp-config-sample\.php)$ {
  deny all;
  return 403;
}

Rechargez nginx avec sudo nginx -t && sudo systemctl reload nginx, puis testez avec curl -I https://votredomaine.com/readme.html. La première ligne de la réponse doit afficher HTTP/2 403.

Plusieurs hébergeurs WordPress managés qui utilisent nginx en interne (Raidboxes, Kinsta, WP Engine, Cloudways) livrent des règles de ce genre par défaut. Cela vaut la peine de vérifier la documentation de l'hébergeur. S'ils ne le font pas, le support ajoutera généralement la règle pour vous sur demande.

Option 3 : hébergement mutualisé où les surcharges .htaccess ne tiennent pas

Certains hébergeurs mutualisés verrouillés exécutent nginx et ignorent complètement .htaccess. D'autres exécutent Apache mais avec des règles AllowOverride restrictives. Si ni l'option 1 ni l'option 2 ne sont disponibles, vous avez trois solutions de repli raisonnables, classées par durabilité :

1. Utilisez une extension de sécurité qui gère le durcissement des fichiers cœur pour vous. Solid Security et All In One WP Security & Firewall ont tous deux un interrupteur « supprimer les fichiers cœur » ou « cacher la version de WordPress » qui s'occupe de readme.html. Wordfence en mode Extended Protection peut également bloquer les fichiers au niveau du WAF. L'avantage est que ces paramètres survivent automatiquement aux mises à jour de WordPress.
2. Videz le fichier via une extension Must Use. Si une règle au niveau du serveur est impossible, l'approche la plus fiable est une petite extension mu qui écrase readme.html et license.txt avec un contenu vide après chaque mise à jour de WordPress. Voir l'article de snippet de code associé dans notre base de connaissances.
3. Supprimez les fichiers manuellement. La solution la plus rapide prend dix secondes via SFTP : il suffit de supprimer readme.html, license.txt et wp-config-sample.php de la racine de WordPress. L'inconvénient est que les mises à jour du cœur de WordPress restaurent les fichiers. Vous devez penser à les supprimer à nouveau après chaque mise à jour majeure, c'est pourquoi une extension ou une règle de serveur web est la meilleure réponse à long terme.

Ce que vous ne devez pas faire

Quelques approches qui apparaissent dans d'anciens articles de blog mais qui sont pires qu'elles n'en ont l'air :

• Renommer les fichiers. Renommer readme.html en readme.html.old a l'air propre mais n'aide pas. WordPress recrée simplement l'original lors de la prochaine mise à jour, et vous avez maintenant deux fichiers au lieu d'un.
• Définir les permissions de fichier à 000. Cela bloque les lectures sur la plupart des hébergeurs, mais la prochaine mise à jour du cœur réinitialise les permissions, et sur certains hébergeurs cela casse aussi la mise à niveau elle-même si WordPress ne peut pas lire le fichier pendant le processus de mise à jour.
• Modifier les fichiers pour supprimer le numéro de version. Tentant mais inutile. WordPress restaure l'original lors de la mise à jour, et même un readme.html modifié confirme toujours que le site fonctionne avec WordPress.

Le schéma est toujours le même : tout ce qui réside dans le répertoire d'installation de WordPress et qui n'est pas protégé par une règle du serveur web sera réinitialisé lors de la mise à jour. Bloquez au niveau du serveur web, ou utilisez une extension qui sait rester active à travers les mises à jour.

Comment vérifier votre configuration

1. Ouvrez https://votredomaine.com/readme.html dans une fenêtre privée. Résultat attendu : une page 403 Forbidden (ou 404 si vous avez choisi la suppression).
2. Même vérification pour https://votredomaine.com/license.txt et https://votredomaine.com/wp-config-sample.php.
3. Si vous voyez encore le contenu du fichier, videz tous les caches qui se trouvent devant le site (Cloudflare, Varnish, caches de page côté serveur comme LiteSpeed Cache ou WP Rocket) et réessayez. Les réponses mises en cache peuvent masquer le changement pendant des heures.
4. Lancez une nouvelle analyse InspectWP. La vérification d'un readme.html exposé dans la section sécurité doit passer au vert.

Pendant que vous y êtes

Le même type de règle FilesMatch ou location mérite d'être appliqué à quelques autres points de terminaison qui apparaissent régulièrement dans les analyses InspectWP : wp-config.php.bak, wp-config.php.swp, .git/, .env, phpinfo.php et tout info.php qu'un développeur a laissé derrière lui pendant le débogage. Même mécanisme, mêmes cinq lignes de configuration, et vous éliminez toute une catégorie d'empreintes occasionnelles et de fuites d'identifiants en une seule fois.