WordPress est remarquable pour sa flexibilité. C’est aussi une cible naturelle: c’est un logiciel répandu, souvent installé avec des thèmes et plugins très variés, et maintenu par des équipes dont la priorité n’est pas toujours la sécurité. Le résultat se voit tous les mois dans les journaux d’accès, les bots de login, et les incidents “classiques” qui auraient pu être évités avec une hygiène de base.
Le hardening WordPress n’est pas une opération ponctuelle. C’est une série de décisions qui réduisent la surface d’attaque, limitent ce que les identifiants peuvent faire si un mot de passe fuit, et rendent la plateforme plus résiliente quand une erreur arrive malgré tout. Dans ce qui suit, je vais parler de sécurité côté utilisateurs, mais aussi de ce que j’ai appris en observant des sites réellement compromis: les mauvaises pratiques qui reviennent, les arbitrages à faire, et les réglages qui donnent le meilleur ratio effort impact.
Le vrai problème n’est pas “WordPress est vulnérable”, c’est “on lui laisse trop de marge”
Quand un site est attaqué, l’enchaînement est rarement spectaculaire. Il suit souvent un schéma simple.
Un attaquant teste des mots de passe courants sur des comptes avec des rôles puissants. Il profite d’un plugin exposé, d’un thème mal maintenu, ou d’une configuration qui autorise des actions non nécessaires. Puis il élève ses privilèges, injecte un script, ou ajoute un utilisateur caché. Souvent, ce n’est pas une “faille 0-day”, c’est une combinaison de facteurs: autorisations trop larges, mises à jour irrégulières, et mauvais contrôle autour de l’accès.
C’est pour ça qu’un projet de hardening WordPress commence par une question qui semble administrative, mais qui change tout: “quels comptes existent, pourquoi ils existent, et ce qu’ils peuvent faire”.
Commencer par l’inventaire: comptes, rôles, et habitudes de connexion
Sur beaucoup de sites, le risque le plus tangible n’est pas la dernière version d’un plugin, c’est la liste des utilisateurs.
- Un compte “admin” qui n’a plus de propriétaire clair. Des comptes créés pour des freelances, puis oubliés. Des rôles trop permissifs: éditeurs qui peuvent installer des plugins, contributeurs qui peuvent gérer des utilisateurs, etc. Des mots de passe faibles, parfois réutilisés sur d’autres services.
J’ai vu des compromis où le script malveillant était déjà en place, mais la porte d’entrée venait d’un compte ancien. Le propriétaire pensait qu’il “n’était plus utilisé”, il ne pensait pas à vérifier le rôle, la date de la dernière connexion, ou l’existence d’une authentification à double facteur. Résultat, l’attaquant avait juste besoin d’un mot de passe.
Concrètement, faites le ménage comme si vous gériez un accès physique à un bâtiment: vous gardez uniquement ce qui doit rester, vous limitez ce qui reste, et vous supprimez ce qui ne sert plus.
Vérifier et réduire les rôles (avant de multiplier les plugins de sécurité)
WordPress ne manque pas de réglages de gestion des rôles, et pourtant on les utilise rarement de manière stricte. L’erreur fréquente est de “simplifier”: tout le monde en administrateur pour éviter des blocages.
Le coût de cette simplification est élevé. Un compte admin compromis donne accès à presque tout: installation, modification de thèmes, édition de fichiers, ajout d’utilisateurs, et parfois export de données ou installation d’un nouvel accès persistant. Un compte éditeur compromis est déjà dangereux, mais généralement plus facile à contenir, surtout si les permissions sont correctement configurées.
Le hardening WordPress orienté utilisateurs vise donc un principe simple: accorder le minimum nécessaire, et faire en sorte qu’un acteur compromis soit limité.
Désactiver les mauvaises pratiques côté authentification
Les attaques sur la connexion sont souvent automatisées, ce qui rend la défense très dépendante de la qualité des mécanismes autour de l’identification.
Les mots de passe: plus que la longueur, c’est la politique
La longueur aide, mais la vraie valeur, c’est la politique et l’outillage. Si votre équipe utilise des mots de passe générés de manière systématique, le taux de succès des attaques par dictionnaire baisse brutalement. Si vous laissez des mots “faciles à retenir”, vous invitez les scripts.
Je recommande de mettre en place:
- un gestionnaire de mots de passe pour les comptes administratifs, une règle de rotation uniquement quand c’est nécessaire (par exemple suspicion de fuite), et surtout l’arrêt des réutilisations.
Le point subtil: changer trop souvent sans raison peut pousser les humains à choisir des variantes proches, et donc à réintroduire une faiblesse. La sécurité ne dépend pas seulement de la politique, elle dépend de son exécution.
Bloquer les accès trop bruyants, mais sans casser la vie des utilisateurs
Le filtrage de la connexion (anti-bruteforce, limitation de tentatives, blocage IP temporaire) est souvent présent dans des plugins de sécurité. Le piège, c’est de les activer “à l’aveugle” sans comprendre le trafic réel. Sur certains sites, des utilisateurs légitimes passent par des réseaux instables, ou utilisent des connexions mobiles avec IP qui changent, ce qui déclenche des blocages injustes.
Une approche pragmatique: surveiller quelques jours les tentatives échouées et ajuster les seuils. Si vous avez un trafic d’administration faible, vous pouvez être plus strict. Si vous avez des équipes distribuées, évitez les paramètres agressifs.
Activer l’authentification forte: le meilleur investissement
L’authentification à double facteur (ou mieux, une méthode résistante au phishing quand votre environnement le permet) réduit le risque même si un mot de passe fuit. L’impact est particulièrement important pour les rôles admin et pour les comptes qui gèrent des plugins, des thèmes ou des utilisateurs.
Le trade-off est réel: la mise en place demande une discipline interne, un parcours de secours (codes de secours, perte de téléphone, changement de matériel), et une gestion claire des jours de maintenance. Mais sur le long terme, c’est généralement l’amélioration la plus rentable.
Si votre équipe a déjà des procédures, vous pouvez la transformer en étape de hardening WordPress: chaque compte sensible doit pouvoir passer par l’authentification forte, au minimum pour les connexions administratives.
Désactiver les fonctionnalités inutiles, surtout celles qui augmentent la surface d’attaque
WordPress est configurable, et beaucoup de sites laissent activées des fonctionnalités qui ne servent pas au projet. Ce n’est pas “dangereux par définition”, mais chaque fonctionnalité active est une surface où une configuration peut mal tourner.
XML-RPC, et l’histoire qui se répète
XML-RPC a longtemps été une cible en raison de sa logique d’appel à distance. Même quand les paramètres sont mieux maîtrisés, le fait est simple: si vous n’en avez pas besoin, le désactiver réduit des chemins possibles vers des méthodes d’attaque. Le bon sens ici ne suffit pas à lui seul, il faut le faire avec méthode et tester les cas d’usage internes.
Quelques plugins, certaines intégrations ou des outils externes peuvent s’appuyer sur XML-RPC. Le hardening WordPress doit donc être conditionné à votre réalité: vous identifiez d’abord les dépendances, puis vous coupez.
Si vous ne savez pas, cherchez dans les logs d’accès si des appels XML-RPC existent, et vérifiez avec l’équipe si des outils l’utilisent. Si vous coupez et que vous cassez une automatisation critique, vous créez un problème de maintenance, parfois plus coûteux que la surface d’attaque elle-même.
Désactiver l’édition de fichiers via l’interface
Permettre l’édition de fichiers depuis l’administration, même si “c’est pratique en dépannage”, est une mauvaise habitude. Une fois la session compromise, cette fonctionnalité permet à un attaquant d’écrire dans l’environnement et d’installer une persistance. Et si l’attaquant ne peut pas écrire, l’impact baisse.
La décision est simple: gardez des mécanismes de déploiement propres (CI/CD, accès SSH verrouillé, ou déploiement via votre méthode de production), et coupez ce canal web.
Verrouiller la sécurité autour des thèmes, plugins et mises à jour
Un plugin non maintenu n’est pas toujours une porte ouverte au monde entier, mais c’est une dette technique. Et la dette technique est exactement ce que les attaques monétisent.
Le piège du “ça marche donc on ne touche pas”
Beaucoup d’équipes évitent les mises à jour pour ne pas risquer de casser. C’est compréhensible, mais il faut transformer cette prudence en méthode.
Une méthode réaliste consiste à:
- appliquer les mises à jour sur un environnement de préproduction, vérifier la compatibilité sur vos pages clés, puis déployer avec un calendrier.
Ce qui ne fonctionne pas, c’est “on met à jour quand quelqu’un a le temps”, car les attaquants ne respectent pas vos plannings. Vous finissez par vous retrouver à rattraper plusieurs versions d’un coup, avec une probabilité accrue de bugs de compatibilité, donc plus de risque.
Contrôler ce qui est installé
Un site “sain” n’a pas 37 plugins actifs dont 20 ne servent à rien. Chaque plugin est un ensemble de code, et chaque ensemble de code est une opportunité de faille, une option de configuration oubliée, ou une compatibilité qui casse.
Ce contrôle doit être continu: revues mensuelles ou trimestrielles. Et surtout, supprimer les plugins inactifs, nettoyer les thèmes non utilisés, et limiter l’installation aux rôles autorisés.
Voici un mini cadre de gestion qui aide à garder le cap:
- Tenir un inventaire des plugins actifs et leurs propriétaires Désinstaller les plugins non utilisés, pas seulement les désactiver Mettre en place une fenêtre de mise à jour régulière (calée sur votre release cycle) Exiger des mises à jour des plugins de sécurité dès que les versions corrigeant une faille sont publiées Surveiller les plugins qui ajoutent des fonctionnalités d’authentification ou de formulaires, car ce sont souvent les plus sensibles
Durcir les paramètres WordPress qui réduisent les privilèges involontaires
Le hardening WordPress ne consiste pas uniquement à ajouter des couches. Il consiste aussi à supprimer des possibilités.
Limiter qui peut créer des utilisateurs et gérer le contenu
Le plus simple à exécuter, et pourtant souvent ignoré, c’est la gouvernance.
- Un éditeur ne doit pas forcément créer des comptes. Un contributeur ne doit pas installer de plugins. Un rôle de maintenance ne devrait pas pouvoir toucher aux réglages de sécurité.
En pratique, vous pouvez fonctionner en mode “workflow”: un compte technique admin gère les changements structurants, les auteurs publient, et les opérations sensibles passent par des procédures internes. C’est moins confortable, mais c’est plus sûr.
Vérifier l’accès aux pages sensibles
Les zones sensibles sont rarement isolées: si un attaquant arrive à un point, il cherche immédiatement à cartographier le reste. Le durcissement inclut la réduction des chemins d’élévation de privilèges.
Par exemple, limiter l’exposition de l’espace d’administration, ajouter des protections contre l’accès automatisé, et surveiller les changements côté utilisateurs et rôles.
Je ne recommande pas la “sécurité par obscurité” comme unique barrière, mais masquer ou limiter certaines surfaces d’accès peut être https://gardewp.fr/securite-wordpress/ un complément utile, surtout contre le bruit automatisé.
Sécuriser la couche HTTP et le serveur sans transformer WordPress en usine à gaz
WordPress n’existe pas seul. Sa sécurité dépend aussi du proxy, du reverse proxy, du CDN, de la configuration du serveur, des en-têtes HTTP et de la gestion des erreurs.
Gérer les en-têtes et limiter l’impact du navigateur compromis
Vous pouvez renforcer la sécurité via des en-têtes de politique (par exemple CSP) et des mécanismes de réduction d’impact pour certaines classes d’attaques. Mais attention aux faux positifs: une politique trop stricte peut casser des scripts de tracking, des intégrations de formulaires, ou des éléments de thème.
Une approche saine consiste à:
- commencer par les protections qui ont peu d’effets de bord, tester sur un site de préprod, puis ajuster progressivement.
TLS partout, pas “quasi partout”
Le chiffrement est la base. Si vous avez des redirections HTTP vers HTTPS mal configurées, ou des sous-domaines qui échappent à la politique, vous créez des brèches. Sur certains incidents, la compromission commence par une session qui n’était pas correctement protégée.
Ce n’est pas un sujet sexy, mais c’est un sujet qui évite des scénarios pénibles.
Journalisation et détection: savoir avant que ça ne se propage
Sans visibilité, on ne sait pas si les réglages “suffisent”. Or les attaques ne laissent pas toujours une trace évidente côté contenu.
Un bon système de journalisation doit vous permettre de répondre à des questions concrètes:
- Qui a tenté de se connecter, et avec quels résultats ? Quelles modifications de rôles ont été effectuées ? Quels fichiers ont été modifiés ? Un compte a-t-il été ajouté récemment sans procédure ?
La détection ne doit pas être uniquement automatisée. Elle doit être actionnable. Si vos logs existent mais que personne ne les consulte, ils ne servent pas.
Protéger les journaux, sinon ils deviennent une cible
Les logs peuvent contenir des informations sensibles. Les stocker de manière accessible depuis le web, ou sans contrôle d’accès, est une erreur. Il faut aussi penser à la rétention, sinon vous perdez les traces au moment où vous en auriez le plus besoin.
Limiter les erreurs humaines: procédures pour les admins et pour les équipes
Il y a une réalité qui revient dans les incidents: la plupart des mauvaises pratiques ne sont pas malveillantes, elles sont “pratiques”. On autorise un accès parce qu’une équipe a besoin de corriger rapidement. On garde un plugin parce que personne ne veut refaire les tests. On crée un utilisateur parce qu’un prestataire est pressé.
Le hardening WordPress cherche à réduire la friction pour les bonnes décisions, et à rendre coûteuses les mauvaises.
Voici une séquence de mise en place qui a bien marché dans des environnements où plusieurs personnes touchent WordPress:
Mettre en place un compte admin technique et des comptes séparés par rôle (auteurs, maintenance, support) Activer l’authentification forte pour les rôles sensibles, avec codes de secours gérés et procédure de remplacement Désactiver l’édition de fichiers côté admin et supprimer les plugins non nécessaires Mettre en place un calendrier de mises à jour testées en préprod, puis déployées Centraliser logs et alertes sur les événements d’authentification, de création d’utilisateurs et de changements de pluginsNotez que cette liste ressemble à une checklist, mais l’idée est surtout de créer une discipline. Le point clé, c’est la cohérence entre les étapes, sinon vous finissez avec des correctifs isolés.
Sauvegardes: la sécurité inclut le plan quand quelque chose arrive
On parle rarement de sauvegardes comme d’un sujet de sécurité, pourtant c’est exactement ce qu’elles sont. Un incident peut être:
- une modification malveillante, un compte compromis qui altère le contenu, un déploiement raté, ou une corruption de fichiers.
Si vous n’avez pas de sauvegardes testées, vous êtes en mode “espérons que ça répare”. Et l’espoir est une stratégie fragile.
Le bon niveau de maturité, c’est:
- des sauvegardes fréquentes, une conservation suffisante pour remonter au bon point, et des tests de restauration sur un environnement isolé.
Le trade-off est le coût: stockage et temps. Mais en cas d’incident, le temps gagné se transforme en stress évité.
Edge cases: quand “durcir” peut casser votre fonctionnement
Les mesures de hardening WordPress peuvent avoir des effets de bord. Voilà les cas que je rencontre le plus souvent.
Premièrement, des robots ou des outils internes utilisent une API ou une fonctionnalité que vous avez supprimée. Par exemple, certaines intégrations de publication ou de synchronisation. Avant de désactiver un mécanisme comme XML-RPC, vérifiez si des services l’appellent.
Deuxièmement, des politiques anti-bruteforce trop strictes bloquent les équipes. Une IP qui change souvent, un VPN d’entreprise, ou une connexion mobile peut déclencher des blocages. Dans ce cas, vous devez ajuster les seuils, ou ajouter des exceptions soigneusement choisies.
Troisièmement, des protections applicatives comme CSP peuvent casser des thèmes, des scripts tiers, ou des widgets. L’approche graduelle et la préprod évitent d’installer des restrictions que vous regrettez le lendemain.
Le quatrième point, c’est la maintenance. Une couche de sécurité de plus peut devenir une dépendance de production. Si vous utilisez un plugin de sécurité, comprenez ses modes de fonctionnement, ses paramètres, et ce que ses règles changent réellement dans l’exécution de WordPress.
Pourquoi “désactiver les mauvaises pratiques” vaut souvent plus que “ajouter des couches”
Il existe un paradoxe: certains sites ajoutent trois plugins de sécurité, deux plugins de cache, et un arsenal d’options, tout en laissant intactes les faiblesses humaines, comme des comptes admin partagés ou des éditeurs autorisés à installer des extensions.
Ajouter est visible, corriger est parfois moins gratifiant. Pourtant, les actions les plus efficaces sont souvent:
- séparer les rôles, réduire les droits, appliquer l’authentification forte, couper les canaux d’administration risqués (édition de fichiers via l’interface), et maintenir un parc logiciel propre.
Le hardening WordPress devient alors une gestion de risque. Vous n’éliminez pas tous les scénarios. Vous réduisez la probabilité, et surtout vous réduisez l’impact quand l’un des scénarios arrive.
Une vision “réaliste” de la sécurité WordPress
Si vous gérez un site WordPress pour un client, une équipe interne ou une activité personnelle, vous n’avez pas besoin de transformer votre plateforme en coffre inviolable. Vous avez besoin d’un système cohérent, avec des garde-fous, des procédures et une capacité de récupération.
C’est là que la sécurité devient durable. Le jour où un plugin cesse d’être maintenu, vous le supprimez. Le jour où un prestataire part, vous désactivez et expirez ses accès. Le jour où un mot de passe fuit, l’authentification forte limite la casse. Le jour où un incident survient, vos sauvegardes testées vous ramènent en arrière sans panique.
D’un point de vue opérationnel, cette approche donne un avantage concret: vous passez d’une sécurité basée sur le hasard à une sécurité basée sur des habitudes solides. Et c’est, à mon avis, la forme la plus utile de hardening.