On pourrait croire que la “version WordPress” est un détail. Sur un site réel, c’est plutôt un repère pour les attaquants, un raccourci pour sélectionner les failles, scripts d’exploit ou méthodes d’identification https://gardewp.fr/securite-wordpress/ qui correspondent exactement à votre environnement. La version affichée dans le code, dans certains en-têtes, ou dans les pages d’erreur donne des informations qui ne rendent aucun service aux visiteurs.
Cacher la version WordPress ne transforme pas votre site en forteresse. Mais c’est une bonne mesure de renforcer sécurité WordPress qui réduit la surface d’information. Et surtout, c’est une action concrète, mesurable, que vous pouvez vérifier vous-même.
Ce que “cacher la version” signifie vraiment
Dans WordPress, la version peut apparaître à plusieurs endroits, pas uniquement dans l’interface d’administration. La plupart du temps, on la voit parce que WordPress expose des métadonnées, ou parce que certaines fonctions ajoutent une “generator tag” (balise de génération) dans le HTML.
Concrètement, vous pouvez rencontrer la version dans :
- le HTML du site (par exemple dans le “generator” ou des attributs liés aux scripts et styles), les en-têtes HTTP (parfois, selon le serveur et la configuration), des flux RSS ou des extraits, certaines réponses d’API (REST, endpoints, éléments liés à la version dans le contenu).
Le but n’est pas de supprimer chaque trace de façon magique. Le but est de réduire ce qui est exposé par défaut, et de contrôler ce qui l’est encore après vos modifications.
Commencer par un état des lieux (sinon vous vous trompez de bataille)
Avant de toucher au code, j’aime bien faire deux vérifications simples. Elles servent à deux choses : comprendre où la version apparaît chez vous, et mesurer l’effet après correction.
1) Ouvrez la page publique dans le navigateur, inspectez le HTML, cherchez des occurrences du mot “WordPress” ou d’un numéro de version (par exemple “6.4.” ou “5.9.” selon votre cas).
2) Faites un test rapide en consultant le code source et, si votre environnement le permet, les en-têtes HTTP.Ce travail initial est important, parce que certains sites “affichent” une version uniquement via un plugin de debug, via un thème qui imprime des métas, ou via une config de cache qui injecte des infos. Si vous supprimez la balise, mais que le thème ou un plugin continue de publier la version ailleurs, vous aurez l’impression que “ça ne marche pas”, alors que vous n’avez corrigé qu’un point.
Les endroits les plus courants où la version se révèle
WordPress lui-même injecte souvent une information de version dans des zones attendues, parce que c’est utile pour certaines fonctionnalités (compatibilité, debugging, caching, et parfois support). Une mesure pragmatique consiste à agir sur ce qui est injecté dans la sortie HTML, sans casser le chargement normal des scripts.
1) La balise “generator” dans le head
C’est le cas le plus classique. Beaucoup de guides parlent de retirer la balise . Elle n’est pas “dangereuse” au sens strict, mais c’est une fuite d’information triviale.
WordPress permet de retirer cette balise en agissant sur un filtre.
2) Les traces liées à la version dans les scripts et styles
WordPress ajoute parfois des paramètres de version aux ressources, par exemple des query strings du type ?ver=6.4.3. Cela aide au contrôle de cache. Si vous supprimez systématiquement ces versions, vous pouvez provoquer des problèmes de mise en cache (les utilisateurs peuvent recevoir une ancienne version de CSS/JS plus longtemps que prévu).
Cacher la version “dans l’esprit” est possible, mais il faut choisir entre :
- réduire l’exposition, conserver une stratégie de cache efficace.
Dans la pratique, je conseille de viser d’abord la balise explicite (celle que vous voyez dans le head), puis d’évaluer si les query strings posent un problème réel pour votre contexte.
3) Les flux RSS
Les flux peuvent répliquer des métadonnées, ou contenir des extraits qui incluent la génération. Si votre objectif est de limiter au maximum la divulgation, il faut aussi vérifier les RSS. C’est rare qu’un attaquant se base exclusivement sur ça, mais si votre politique de sécurité est stricte, c’est un endroit logique.
4) Les réponses d’API et le diagnostic
Les endpoints REST sont souvent exposés, mais ils ne publient pas systématiquement la version en clair comme le ferait un meta generator. En revanche, des erreurs ou des pages de debug peuvent faire ressortir des informations. Si vous utilisez un plugin qui affiche des détails de version, ou si votre serveur renvoie des pages d’erreur trop verbeuses, la version peut réapparaître.
Ici, le “cacher la version” devient surtout une question de cohérence : ce que vous supprimez dans le head doit être cohérent avec ce qui est renvoyé dans les autres surfaces.
L’approche pratique : agir proprement dans WordPress
L’approche la plus sûre consiste à utiliser un thème enfant (ou un plugin “site-specific”) pour éviter de perdre vos modifications lors d’une mise à jour.
L’idée : retirer ce que WordPress injecte dans la sortie, sans neutraliser la logique interne de WordPress (compatibilité, cache, dépendances).
Retirer la balise generator proprement
Dans functions.php de votre thème enfant, vous pouvez ajouter un filtre pour désactiver la balise de génération. Un exemple classique consiste à supprimer la sortie du generator.
Le principe est simple : au lieu de laisser WordPress imprimer la balise, vous remplacez la fonction qui la produit.
Si vous préférez éviter les erreurs, je recommande de copier le bloc minimal, puis de tester.
Attention : selon la version WordPress exacte et le thème, la méthode peut varier légèrement, notamment si WordPress ou des plugins ont déjà modifié l’action/filtre. Le test après modification est non négociable.
Éviter de casser le cache en touchant aux “ver=”
Quand WordPress ajoute ?ver=... aux ressources, ce n’est pas toujours un problème de sécurité en soi. C’est plutôt un signal utile pour le cache busting. Si votre serveur et votre CDN appliquent une stratégie de cache raisonnable, la version dans ver= n’offre pas forcément un levier exploitable direct, mais elle confirme précisément votre version.
Le compromis, c’est de décider si votre objectif est :
- “ne plus afficher la version lisiblement dans le HTML” (mesure très utile, faible risque), ou “réduire aussi la version dans les URLs des assets” (plus intrusif, risque de cache incohérent).
Dans une approche pratique, commencez par le premier objectif. Une fois en production, vous pouvez mesurer l’impact avant d’aller plus loin.
Surveiller l’effet côté cache et minification
Beaucoup de sites utilisent une couche de cache (objet cache, full page cache, reverse proxy) et parfois de la minification. Quand vous modifiez la sortie HTML via functions.php, certains caches peuvent continuer à servir l’ancienne page.
J’ai déjà vu des équipes valider à tort, parce qu’elles avaient supprimé la balise generator, puis le cache a continué à servir l’ancien HTML pendant des heures. La vérification doit se faire sur :
- une page fraichement servie, idéalement après purge du cache (y compris CDN si vous en avez un).
Mettre en place un patch “propre” via thème enfant ou plugin
Le meilleur endroit pour ce genre de modification dépend de votre organisation.
- Si vous maîtrisez le thème et que vous êtes à l’aise avec l’approche thème enfant, c’est souvent le chemin le plus direct. Si votre site change fréquemment de thème, ou si vous voulez centraliser les durcissements pour plusieurs sites, un mini plugin dédié est plus élégant.
Dans tous les cas, le test doit couvrir au moins :
- la page d’accueil, une page standard, un flux RSS si vous en utilisez, une page qui déclenche des scripts ou des comportements différents.
Le piège classique : vouloir “désactiver partout” sans vérifier
Je l’ai fait une fois, sur un site avec un plugin de performance agressif. J’avais supprimé la version sur les assets, et quelques heures après, le style principal n’arrivait plus pour certains visiteurs, parce qu’un cache intermédiaire avait servi un bundle vieux de plusieurs jours. Aucun “hack” ici, juste un effet secondaire.
La leçon : quand vous touchez aux versions dans les URL de ressources, testez aussi la cohérence sur plusieurs chemins, et prévoyez une purge.
Vérifier après modification : ce que vous devez voir (ou ne plus voir)
Une fois vos changements en place, vous devez vérifier avec une logique de preuve simple : si la version n’apparaît plus dans les endroits ciblés, vous avez réussi au moins sur ce point.
Voici une procédure de contrôle rapide.
C’est volontairement orienté “constat” plutôt que “théorie”. Le durcissement, ce n’est pas ce que vous pensez avoir fait, c’est ce que le visiteur récupère réellement.
Et les en-têtes HTTP dans tout ça ?
Un point qui revient souvent : “je veux cacher WordPress aussi dans les en-têtes”. Sur ce sujet, je préfère être prudent.
- Certains détails peuvent être injectés par PHP, le serveur web (Nginx, Apache), ou des couches comme le reverse proxy. WordPress lui-même n’a pas toujours la main sur tout ce qui est visible. Les plugins de sécurité peuvent aussi influencer certains en-têtes (et parfois, c’est plus stable que de bricoler au niveau serveur).
Si vous voulez aller plus loin que la balise generator, travaillez en couches, en commençant par WordPress, puis serveur, puis CDN. Et dans chaque couche, prenez en compte le fait que trop de suppression peut compliquer le diagnostic quand quelque chose casse.
Une bonne pratique, c’est de limiter vos changements de haut niveau à WordPress, puis d’orienter les en-têtes côté serveur via une politique claire de durcissement (et documentée). Ce n’est pas nécessaire pour “cacher la version” dans l’objectif minimum, mais c’est cohérent si vous voulez une hygiène globale.
Trade-offs réels : sécurité, maintenance, performance
Cacher la version est utile, mais il y a des compromis.
Modifier functions.php et maintenance
Quand vous touchez functions.php, vous introduisez un code qui doit survivre aux évolutions du thème. Le thème enfant limite le risque, mais il faut quand même :
- garder une trace de vos modifications, éviter de coller du code complexe sans commentaires, tester après mise à jour majeure.
Cache et cohérence
Le risque le plus concret n’est pas l’échec “sécurité”, c’est la cohérence. Supprimer les versions sur les assets peut déclencher des comportements de cache bizarres. Même si ce n’est pas une menace directe, c’est un coût opérationnel.
Effet sur la détection des problèmes
Des équipes techniques apprécient de voir la version pour déboguer rapidement. Si vous la cachez partout, vous perdez un signal de diagnostic. Sur un parc de sites géré, on compense cela avec :
- journaux côté serveur, monitoring applicatif, variables de build internes non exposées publiquement.
C’est un compromis à assumer. Je préfère cacher la version quand elle est exposée publiquement sans nécessité, mais garder une traçabilité interne.
Exemple de stratégie “raisonnable” pour un site WordPress standard
Si je devais résumer une approche que j’ai vue fonctionner en environnement réel, sans faire de dégâts :
- D’abord, supprimer la balise generator. Ensuite, vérifier les flux RSS si vous souhaitez une réduction plus globale de l’information. Puis seulement, si votre modèle de risque le justifie, évaluer ce qu’il faut faire pour les paramètres de version dans les assets.
Ce chemin réduit le risque de casser le cache, tout en atteignant l’objectif principal, réduire la divulgation.
Deuxième niveau : quand aller plus loin devient pertinent
Il arrive qu’un site soit exposé à une pression particulière (trafic très bruité, tentatives automatiques fréquentes, environnement très ciblé). Dans ces cas, on peut vouloir réduire davantage.
Le point d’attention, c’est que plus on “bricole”, plus on augmente le risque de régression fonctionnelle ou de conflit avec un plugin de performance.
J’ai l’habitude de poser une règle interne : si la modification n’est pas testable facilement, ou si elle a un risque non trivial d’affecter le rendu, je la reporte à une fenêtre de déploiement planifiée, avec rollback clair.
Une mini check de cohérence avant d’élargir
- Est-ce que votre site utilise un plugin de cache ou de minification qui gère déjà la version des assets ? Est-ce que vous avez un CDN qui peut faire varier les réponses HTML ? Est-ce que vos pages de contenu sont servies en mode SSR, full page cache, ou HTML pré-généré ? Est-ce que vos logs remontent bien les erreurs après déploiement ? Est-ce que vous avez un moyen simple de purger tout cache lié ?
Si une réponse est “je ne sais pas”, mieux vaut rester sur le premier niveau, celui qui est le plus stable.
Résultat attendu : ce qui compte vraiment côté visiteur
Une fois en place, le visiteur ne doit plus lire une version de WordPress clairement exposée dans le head. Si vous avez fait la chasse aux fuites évidentes, il ne devrait plus y avoir de mention directe du numéro de version dans le HTML public.
Et surtout, le site doit continuer à fonctionner correctement, chargement des scripts compris, sans effet de bord de cache.
La sécurité, ce n’est pas seulement “cacher”. C’est aussi ne pas créer d’autres problèmes en échange, ce qui est malheureusement fréquent quand on cherche une parade rapide.
Checklist de déploiement (courte, mais utile)
Voici le dernier contrôle que je recommande avant de considérer le travail “terminé”.
Test sur une page fraîche (cache purgé). Vérification du head (balise generator absente ou neutralisée). Recherche de l’occurrence exacte de votre version dans le HTML. Vérification d’un flux RSS si applicable. Vérification chargement CSS et JS sans erreurs.Si ces points passent, vous avez une base solide et cohérente, sans vous engager dans une chasse trop agressive.
Cacher la version WordPress est une mesure de durcissement raisonnable. Elle n’empêche pas une compromission si une faille existe ou si un plugin est vulnérable, mais elle retire un signal utile. Pour moi, c’est précisément le genre d’action qui renforce la sécurité WordPress de manière pragmatique : peu de risque quand on cible les bons points, amélioration mesurable, et amélioration qui se combine naturellement avec le reste, mises à jour, durcissement des comptes, plugins de qualité, et hygiène serveur.