Quand on parle de sécurité WordPress, on pense souvent aux mises à jour, aux mots de passe, au durcissement du serveur. Pourtant, il y a un détail qui revient dans beaucoup d’audits: l’information technique que WordPress dévoile, parfois malgré vous, sur sa version. On ne fait pas ça pour la curiosité, on le fait parce que des attaquants automatisent l’identification. Plus ils savent précisément ce que vous exécutez, plus ils peuvent choisir le bon chemin, au bon moment.
Masquer la version de WordPress ne vous rend pas “invulnérable”. Ce n’est pas une armure. C’est plutôt réduire les indices disponibles et compliquer la tâche d’un scanner opportuniste. La bonne approche consiste à combiner plusieurs petites suppressions d’empreintes, sans casser le fonctionnement de votre site.
Ce que “masquer la version” veut vraiment dire
Dans WordPress, la version peut apparaître à plusieurs endroits:
- dans des balises HTML, notamment le tag generator et parfois des éléments “readme” dans des en-têtes HTTP (par exemple via certaines configurations, certains headers) dans des flux RSS et Atom dans des URLs de ressources chargées par le navigateur (par exemple paramètres ?ver=... sur fichiers CSS/JS) dans le code côté serveur quand un outil expose le numéro de version par un endpoint ou une ressource statique
Beaucoup de gens ne traitent que l’option “readme.html”. C’est utile, mais ça ne suffit pas. Inversement, essayer de tout supprimer “à la main” en modifiant trop profondément peut créer des effets secondaires: caching cassé, compatibilité navigateur en baisse, ou pages qui cessent d’afficher des styles correctement. Le but est de viser les indices les plus fréquents et de garder WordPress stable.
Comprendre pourquoi WordPress affiche sa version
WordPress a des raisons pratiques d’exposer la version. Les balises “generator” aident au diagnostic, et les paramètres ?ver= servent souvent à invalider le cache quand WordPress change de build. Les flux contiennent des métadonnées pour faciliter la compatibilité et le débogage.
Le problème, c’est que ce diagnostic est lisible par tout le monde. Si un script peut déterminer “vous êtes en 6.x.y”, il peut ensuite tester des patterns d’exploitation associés. Ce n’est pas le seul facteur, mais dans un environnement réel, c’est un gain immédiat pour l’attaquant.
Un point important: masquer la version ne remplace pas la mise à jour. Si vous restez sur une version vulnérable, vous perdez surtout du temps, parce que des attaques continuent d’essayer même sans numéro exact. La réduction de surface sert à diminuer la probabilité de ciblage opportuniste, pas à neutraliser une vulnérabilité non corrigée.
Les endroits à vérifier sur votre site
Avant d’agir, je conseille un mini audit “à froid” depuis l’extérieur. Ouvrez votre site dans un navigateur, puis:
Inspectez la source HTML et recherchez WordPress et generator Vérifiez le flux RSS principal si vous l’avez (les versions et métadonnées peuvent s’y retrouver) Contrôlez la réponse HTTP via les outils de développement (headers) Observez les requêtes réseau, surtout les fichiers CSS/JS, et repérez si les URLs portent un ?ver=...Ça vous donnera une base concrète. Deux sites “WordPress” peuvent ne pas divulguer la version de la même manière, selon votre thème, vos plugins, vos caches, et la façon dont votre serveur module les headers.
Méthode pragmatique 1: retirer l’empreinte “generator” et readme
C’est souvent le point de départ, parce qu’il ne touche pas au chargement des assets au sens strict, et qu’il réduit un grand classique des scanners.
Retirer le generator dans le HTML
Dans WordPress, le tag generator peut être injecté via wp_head. Vous pouvez le supprimer en ajoutant un petit bout de code dans un plugin maison (ou dans functions.php de votre thème enfant).
Voici une approche souvent utilisée:
Add_action('init', function () Remove_action('wp_head', 'wp_generator'); );Selon votre configuration, cette suppression peut suffire à faire disparaître l’indication “WordPress x.y” dans la partie HTML. Elle ne garantit pas l’élimination totale de toutes les traces ailleurs, mais c’est un bon premier niveau de réduction.
Supprimer readme.html
WordPress installe aussi souvent un fichier readme.html ou, selon les cas, une ressource équivalente dans la racine. Un attaquant le sait, donc il regarde.
S’il est présent, vous pouvez le supprimer à condition de https://gardewp.fr/securite-wordpress/ ne pas casser un usage interne (rare). L’approche la plus saine est de l’effacer, puis de vérifier que votre site ne s’appuie pas sur ce fichier.
En pratique, je le fais seulement après avoir vérifié que personne n’en dépend (certains environnements ajoutent des scripts de monitoring interne, mais c’est exceptionnel).
Méthode pragmatique 2: gérer l’exposition via les flux RSS
Les flux RSS sont une autre source fréquente. Les lecteurs RSS et agrégateurs affichent parfois des métadonnées, et des scanners peuvent s’en servir.
La bonne stratégie consiste à supprimer la partie “generator” des flux si elle apparaît chez vous. Là encore, la logique doit être basée sur votre observation initiale. Si votre flux ne montre rien, inutile de toucher.
Souvent, la présence vient de l’insertion de balises côté WordPress pour les flux. Vous pouvez envisager une suppression conditionnelle pour feed uniquement.
Exemple typique (à adapter selon ce que vous observez):
Add_action('wp_footer', function () // pas d’action ici, juste pour rappeler: évitez les suppressions aveugles );Je préfère ici vous guider par observation plutôt que de donner “une recette unique”, car les hooks exacts varient selon versions, plugins de flux, et thèmes. L’erreur classique, c’est de copier-coller un fragment de code qui retire plus que prévu, et de se retrouver avec des flux partiellement cassés.
Ce que je fais en audit:
- je demande “quelle URL de flux divulgue la version?” je confirme que le flux reste valide W3C après modification je teste 2 clients différents (un agrégateur et un lecteur local)
Méthode pragmatique 3: réduire les fuites dans les en-têtes HTTP
Certaines traces passent par les headers. Le point délicat, c’est que les headers dépendent surtout du serveur web (Nginx, Apache), de vos réglages de sécurité, et parfois de plugins.
Masquer “la version WordPress” dans les headers est rarement un réglage unique côté WordPress pur, parce que c’est souvent le serveur ou un plugin qui ajoute l’information.
Ce que vous pouvez faire concrètement:
- vérifier si des headers comme X-Powered-By sont présents (dans certains environnements) vérifier les headers de réponse qui contiennent explicitement “WordPress” supprimer ce qui n’apporte rien, mais sans casser des mécanismes de compatibilité
Si vous voyez une fuite nette dans un header précis, vous pouvez la corriger à la source, soit dans la configuration serveur, soit via un petit plugin WordPress qui filtre des headers. Mais comme les headers varient selon le stack, la correction “aveugle” est risquée.
Mon conseil: partez toujours d’un relevé réel. Un exemple de pratique: si votre sécurité WordPress repose sur un reverse proxy, c’est souvent lui qui rajoute des informations. Dans ce cas, attaquer WordPress directement ne fera pas grand-chose.
Méthode pragmatique 4: gérer le paramètre ?ver= des ressources
L’un des indices les plus visibles à l’œil nu, ce sont les URLs du type:
/wp-content/themes/mon-theme/style.css?ver=6.4.3
Ici, WordPress peut exposer sa version dans le paramètre de version des assets, notamment via l’enqueue de scripts et styles. Pour un attaquant, cela ressemble à “je sais exactement ce que vous exécutez”.
Mais c’est aussi un mécanisme de performance et de cache control. Quand la version change, le navigateur évite parfois d’utiliser une ancienne copie du fichier.
Il existe des solutions pour retirer ou neutraliser ce paramètre, mais elles impliquent un compromis: vous pouvez forcer vos utilisateurs à recharger plus souvent, ou dépendre d’un cache côté serveur plus robuste.
Option A: neutraliser les paramètres de version côté WordPress
Une approche consiste à filtrer la sortie des URLs et supprimer le ?ver=... sur les styles et scripts, au moins quand cela n’est pas requis.
Vous pouvez utiliser un filtre qui modifie la version des scripts et styles, ou une logique qui supprime le paramètre.
Je vous donne un schéma, à adapter, parce que les détails exacts dépendent des versions et des thèmes:
Add_filter('script_loader_src', function ($src) Return remove_query_arg('ver', $src); , 15); Add_filter('style_loader_src', function ($src) Return remove_query_arg('ver', $src); , 15);
L’idée est simple: si l’URL contient un paramètre ver, vous le retirez.
Le compromis à ne pas ignorer
J’ai vu des sites qui “fonctionnent” après ce changement, puis qui deviennent pénibles à déboguer lors d’un déploiement, parce que le cache navigateur ne se rafraîchit pas comme prévu. Selon votre configuration, vous vous appuyez peut-être sur:
- un purge cache côté CDN des en-têtes Cache-Control bien réglés un bundling via le thème ou un plugin de build (Webpack, Vite, etc.)
Si vous avez un pipeline clair et un cache maîtrisé, enlever ?ver= peut être acceptable. Si vous dépendez beaucoup de l’invalidation automatique de WordPress, vous allez perdre un signal pratique.
Dans le doute, je préfère neutraliser les traces les plus “dangereuses” (generator, readme, endpoints), et garder les paramètres de version sur les assets. Ce n’est pas “tout ou rien”, c’est un choix d’équilibre.
Méthode pragmatique 5: réduire les indices via wp-json et endpoints
WordPress expose énormément via l’API REST. La version WordPress n’est pas forcément incluse telle quelle dans toutes les réponses, mais certains endpoints renvoient des métadonnées, et certains plugins ajoutent leurs propres structures.
Ce point est souvent mal traité parce qu’on confond:
- l’exposition de la version WordPress l’exposition de l’existence d’un endpoint l’exposition des capacités d’authentification
La bonne approche n’est pas “masquer tout”. Elle est double:
Limiter les endpoints inutiles Corriger le contrôle d’accès (côté authentifiés seulement, sans fuite inutile)Masquer la version ici, quand elle apparaît, se fait surtout en réduisant ce que renvoient vos réponses. Mais toucher au REST sans comprendre ce que renvoient réellement vos endpoints peut casser des fonctionnalités de thème ou de plugins.
Si vous constatez une fuite de version précise dans une réponse REST particulière, le meilleur correctif est ciblé, pas global.
Plugins de sécurité et “masquage”: utile, mais pas magique
Beaucoup de plugins “security” proposent une option pour “masquer la version WordPress”. Parfois, c’est un ensemble de suppressions faciles (generator, readme, certaines métadonnées). D’autres fois, c’est une logique plus large, qui peut aussi affecter le chargement des assets.
Mon expérience: ces options marchent bien quand elles restent ciblées. Elles deviennent plus risquées quand elles se mélangent avec d’autres modules, comme l’optimisation assets, la compression HTML, ou la mise en cache agressive.
Si vous utilisez un plugin pour ça, je vous recommande:
- de tester après activation, sur une page publique et sur une page login de vider le cache (CDN + cache plugin si présent) de vérifier le rendu visuel, surtout après une mise à jour WordPress
Et surtout, gardez une logique de “preuve”. Si le plugin promet de masquer la version, vérifiez vous-même ce que votre navigateur et vos outils HTTP affichent réellement.
Ce qui ne vaut pas la peine, ou pas au bon endroit
Il existe des tentatives trop agressives qui font perdre plus qu’elles ne gagnent.
Par exemple:
- supprimer les paramètres de version de façon globale sans maîtriser l’invalidation cache filtrer des headers au hasard, sans savoir qui les ajoute désactiver des hooks nécessaires parce qu’un exemple de blog a “marché” ailleurs
Sur un site réel, les effets secondaires coûtent vite du temps. Un site qui semble “ok” une journée peut devenir une source de tickets après la prochaine mise à jour.
Une approche réaliste en “couches”
Pour masquer efficacement la version, j’utilise mentalement une logique en couches. Chaque couche réduit un vecteur. Ensemble, ça rend l’identification moins directe.
- réduire l’exposition HTML via generator et les ressources statiques comme readme.html réduire l’exposition dans les flux si votre configuration les divulgue traiter les assets de manière réfléchie, pas automatique, parce que le paramètre ver joue souvent un rôle de cache invalidation corriger les headers uniquement quand une fuite réelle est observée éviter de toucher au REST et aux contrôles d’accès sans cible claire
C’est cohérent avec la façon dont les scanners fonctionnent: ils cherchent une chaîne exploitable et ils compilent des signaux. Vous cassez la chaîne, au moins partiellement.
Exemple concret d’un cas typique (ce que j’ai déjà vu)
Sur un site d’une petite entreprise, la version WordPress apparaissait clairement dans la source HTML via le generator, et dans les requêtes réseau via ?ver=6.x.y sur certains assets. La personne avait activé un plugin qui “masquait la version”, mais elle n’avait pas vérifié l’effet réel dans le navigateur.
Résultat après correction ciblée:
- le generator avait disparu l’entrée readme.html n’était plus accessible le ?ver= restait sur certains assets, mais la page ne contenait plus de mention “WordPress x.y” dans la source principale
Le site semblait plus “opaque” pour un scanner simple. Et le plus important, aucune différence visible n’est apparue après purge du cache. Le compromis était acceptable, parce que le cache invalidation restait assuré, et l’exposition principale avait été réduite.
Vérifier l’efficacité, sans tomber dans le piège
Le piège le plus courant: on croit que “c’est masqué” parce que Google ou un outil de test ne montre plus la version. Ce n’est pas une preuve suffisante.
Une vérification correcte consiste à observer:
- la source HTML de pages publiques (accueil, page type) les flux si vous les publiez les en-têtes HTTP un chargement de page “avec cache” et après purge
Le scanner d’attaquant réel ne se contente pas de l’une de ces vues. Il combine souvent plusieurs indices. Votre objectif est de réduire la somme, pas juste un seul affichage.
Mises à jour et sécurité WordPress: le point qui prime
Masquer la version fait gagner un peu de temps à l’attaquant, mais la sécurité WordPress reste centrée sur:
- les mises à jour WordPress, thème et plugins la réduction des privilèges la protection contre les mots de passe faibles la limitation de surface sur l’authentification et les endpoints la surveillance (logs, détection d’anomalies)
J’ai vu des équipes passer plusieurs heures à retirer des indices “parfaitement”, puis oublier une mise à jour de plugin avec une vulnérabilité connue. Les attaquants ne punissent pas le détail, ils punissent la vulnérabilité réelle.
Le bon ordre, en pratique, c’est: corriger les risques critiques d’abord, puis durcir la surface passive comme le masquage de version.
Checklist rapide (sans bricoler au hasard)
Si vous voulez une démarche efficace, gardez ces points en tête dans un ordre logique:
Identifiez où la version apparaît chez vous (HTML, headers, flux, assets) Supprimez ce qui est facilement et sûrement corrigeable, comme le generator et les fichiers readme évitez les suppressions globales sur les assets sans stratégie de cache Validez le rendu et la compatibilité des flux Vérifiez après purge de cache et après une mise à jour WordPressCette discipline évite de “gagner” sur un indicateur et de “perdre” sur la stabilité.
Conclusion opérationnelle
Masquer la version de WordPress efficacement, ce n’est pas un bouton magique. C’est une série de corrections ciblées, fondées sur ce que votre site divulgue réellement, et sur les compromis que vous pouvez accepter, notamment côté cache.
Si vous partez d’une observation concrète, que vous supprimez l’empreinte generator et les ressources triviales comme readme.html, puis que vous traitez prudemment les flux et les paramètres de version des assets, vous réduisez nettement la facilité de reconnaissance. Et vous le faites sans transformer votre site en expérience fragile.
En sécurité WordPress, c’est rarement la seule mesure qui compte. Mais c’est une brique propre, raisonnable, et souvent rentable, surtout quand elle s’ajoute à des mises à jour rigoureuses et à une hygiène de configuration solide.