Le hardening de WordPress, c’est le fait de réduire la surface d’attaque et de rendre votre site plus difficile à compromettre. Le mot peut faire peur, mais la méthode n’a rien de mystique. On vise surtout des choses très concrètes: limiter ce qui peut être exécuté, cloisonner ce qui peut tomber, réduire la visibilité pour les attaquants, et renforcer les contrôles qui détectent ou empêchent les mauvaises actions.
J’ai souvent vu des sites “à jour” rester vulnérables, pas à cause d’un exploit spectaculaire, mais à cause de détails ordinaires: des identifiants admin réutilisés, un hébergement mal configuré, des permissions trop larges sur des dossiers, un thème ou un plugin laissé en l’état, et parfois même un wp-config.php exposé. Le hardening ne supprime pas tout risque, il change le rapport de force.
Partir du bon diagnostic, avant de bricoler
Avant de toucher à la configuration, prenez une photo de l’existant. Cela vous évite de corriger dans le noir, et surtout de ne pas confondre “ce que vous avez changé” avec “ce qui a causé un problème”. Vous cherchez aussi à repérer les priorités.
Commencez par vérifier trois axes:
1) Où se situe le point d’entrée. Est-ce que WordPress est sur la racine du domaine, dans un sous-dossier, ou derrière un proxy? Est-ce que votre site est accessible en HTTP et HTTPS, ou uniquement en HTTPS? Les redirections et l’architecture comptent, même pour des mesures “WordPress”.
2) Ce qui s’exécute réellement. Un WordPress “standard” peut être enrichi par un plugin de sécurité, un constructeur de page, un LMS, un importeur, un outil de formulaire, etc. Plus vous ajoutez du code externe, plus vous augmentez la surface d’attaque. La règle pratique: ce que vous ne surveillez pas, vous le subissez.
3) Les paramètres qui reviennent dans les incidents. Les mots de passe faibles, les droits excessifs, les comptes admin inutiles, et les mises à jour “temporisées” sans justification. À chaque fois, il y a une discipline à retrouver.
Si vous avez accès à un environnement de préproduction, c’est idéal. Sinon, au minimum, préparez un plan de rollback clair: sauvegarde, accès admin fonctionnel, et fenêtre de maintenance si vous touchez aux règles de connexion et aux permaliens.
Verrouiller l’accès à l’administration (le vrai point névralgique)
La plupart des attaques WordPress suivent un chemin classique: ils trouvent un moyen d’accéder à l’interface d’administration, puis ils installent quelque chose (un plugin, un thème modifié, du code dans un fichier, ou un utilisateur caché). Donc, le hardening doit d’abord rendre cette étape plus difficile.
Sur ce sujet, j’ai une règle: ne misez pas uniquement sur “un plugin”. Un plugin de sécurité est utile, mais il ne remplace pas des décisions d’architecture. Par exemple, si votre serveur autorise des connexions sans limitation brute force, même un bon plugin peut être submergé.
Dans la pratique, le plus efficace est souvent la combinaison de contrôles:
- limitation du nombre d’essais de connexion (avec une politique adaptée à votre trafic), journalisation et alertes, validation de session et durcissement côté cookies, et, très souvent, changement de l’hygiène des comptes.
Les comptes, justement. Je vois encore trop de sites avec un compte “admin” historique, créé lors de l’installation, dont le mot de passe n’a jamais été mis à jour. Même si le compte n’est pas utilisé tous les jours, il reste un levier.
Un bon durcissement, c’est aussi de réduire les droits. Un éditeur n’a pas besoin de gérer des plugins. Un contributeur n’a pas besoin d’installer des thèmes. Sur WordPress, ça se joue dans les rôles, et dans la gouvernance.
Mettre à jour, mais intelligemment
La mise à jour n’est pas glamour, mais c’est une des actions les plus rentables. WordPress, les plugins et les thèmes corrigent régulièrement des failles connues. Les attaquants exploitent ce qui est public, et ils automatisent.
Le point d’attention, c’est la méthode. Mettre à jour “tout d’un coup” sur un site complexe peut provoquer des incompatibilités. L’approche que je recommande ressemble à ceci: mettre à jour WordPress core d’abord, puis traiter les plugins et thèmes de manière progressive, en commençant par ceux qui exposent le plus.
Quels sont ceux qui exposent le plus? Ceux qui gèrent le front (builders), ceux qui reçoivent des données (formulaires), ceux qui ont des fonctionnalités d’import ou d’API, et ceux qui manipulent des fichiers. Ce sont souvent les plus “touchy”.
Et gardez une discipline sur les plugins inutilisés. Si un plugin n’est plus utilisé, le désactiver puis le supprimer réduit immédiatement la surface. La suppression est parfois plus propre que la “désactivation”, car un plugin désactivé peut parfois laisser des options ou des fichiers, selon son design.
Renforcer les mots de passe et le contrôle des identités
C’est un sujet que les gens rangent dans le tiroir “on le fait plus tard”. Pourtant, c’est là que se joue une grande partie du risque. Un mot de passe solide, ce n’est pas une phrase compliquée. C’est une règle simple: longueur et unicité.
Si vous avez la possibilité d’ajouter une authentification à deux facteurs pour les comptes administrateurs, faites-le. Même sans en faire un projet massif, cela protège l’étape la plus ciblée. Attention au détail opérationnel: assurez-vous que les administrateurs savent quoi faire en cas de perte de device, et que la procédure de récupération est testée.
Autre amélioration utile: imposer une politique de changement de mot de passe en cas d’employé parti, de fuite suspectée, ou de changement de prestataire. J’ai déjà vu des incidents où l’entreprise croyait que “le compte a été désactivé côté RH”, mais le compte WordPress était resté actif.
Sécuriser wp-config.php et les fichiers sensibles
Le fichier wp-config.php est l’un des endroits les plus sensibles d’un site WordPress. Il contient des informations cruciales comme les identifiants de base de données et des constantes qui pilotent le comportement du site.
Le hardening ici se concentre sur deux choses: s’assurer que le fichier n’est pas exposé par le serveur, et limiter l’accès de lecture. Sur beaucoup d’hébergements, la bonne configuration existe par défaut. Mais j’ai déjà vu des permissions trop ouvertes, ou des règles de serveur incohérentes lors de migrations.
Si vous manipulez des permissions, soyez prudent. Un site peut “marcher” même avec des droits incorrects, puis casser au prochain déploiement, ou lors d’un changement de propriétaire. L’approche raisonnable consiste à suivre la documentation de votre hébergeur, et à ne pas appliquer des “recettes” au hasard.
Pour réduire d’autres expositions, vérifiez aussi:
- l’absence de fichiers de type .bak, .swp, ou sauvegardes laissées par un éditeur, la présence de fichiers uploads non contrôlés, et la cohérence des droits sur les dossiers uploads et wp-content.
Un mini contrôle avant modifications (sans se compliquer)
Voici un premier tour de table simple, à faire avant de lancer des changements plus lourds:
- sauvegarde complète disponible (fichiers et base de données) accès admin vérifié et stable comptes admin revus (suppression ou réduction des comptes inutiles) thèmes et plugins non utilisés identifiés paramètres HTTPS et redirections confirmés
Durcir les réglages WordPress de base
WordPress propose des réglages qui semblent anodins, mais qui jouent un rôle. D’abord, la visibilité. Si votre site est en phase de chantier, utilisez un mode de confidentialité cohérent, pas juste “je n’ai pas encore mis de contenu”. Ensuite, la partie “discussion” et “commentaires” mérite une attention: modérer les commentaires, limiter le spam, et contrôler qui peut publier.
Ces réglages ne remplacent pas une protection applicative, mais ils réduisent les vecteurs d’abus. Par exemple, des commentaires non modérés servent parfois de relais pour des liens malveillants, et des formulaires mal sécurisés deviennent des portes d’entrée.
Pensez aussi aux permaliens. Des permaliens https://gardewp.fr/securite-wordpress/ “propres” et cohérents n’améliorent pas la sécurité à eux seuls, mais ils rendent l’exploitation opportuniste un peu moins pratique, et ils évitent des configurations fragiles. Ici, le vrai bénéfice est d’avoir une structure stable. Changer les permaliens à la légère, sur un site en production, peut créer des erreurs et des problèmes de caching, et déclencher des comportements inattendus.
Gérer le thème et les plugins comme on gère du code en production
C’est la partie où beaucoup de sites se fragilisent. Un plugin activé par besoin ponctuel reste en place pendant des années. Un thème enfant modifie des fichiers sans tests. Un code personnalisé est déposé dans un endroit non documenté. Dans ce genre de situation, le hardening devient un exercice de “nettoyage et de discipline”.
Je recommande de considérer WordPress comme une application. Cela implique:
- des versions suivies (un inventaire des plugins et thèmes), un cycle de mise à jour, et une stratégie pour le code sur mesure.
Pour le code sur mesure, privilégiez une approche maintenable: child theme quand c’est nécessaire, ou intégration propre dans un endroit prévu. Évitez les hacks qui modifient directement des fichiers core. Ils se brisent au moment d’une mise à jour, et la prochaine personne qui maintient le site hérite d’une dette technique.
Protéger l’upload et ce que le serveur accepte
Le dossier uploads est central, parce qu’il stocke les fichiers accessibles publiquement. Ce n’est pas forcément “dangereux” en soi, mais cela exige de la cohérence. Le serveur doit refuser ce qui ne devrait pas être autorisé. Le téléchargement d’un fichier n’est pas seulement une question de format, c’est aussi une question de type réel et d’exécution.
Selon votre environnement, vous pouvez renforcer les règles pour empêcher l’exécution de scripts dans des dossiers d’uploads. Mais le plus important reste la validation et le contrôle des types acceptés via WordPress et via le serveur.
Un piège courant: laisser un formulaire d’upload ouvert sans restrictions ou sans contrôle. Un attaquant n’a pas besoin de réussir un exploit complexe si une fonction basique lui permet d’importer un fichier qui passe pour “image”.
Pour les formulaires, testez. Vraiment. Un “ça a l’air d’accepter seulement des images” ne suffit pas. Faites des tests sur staging, avec des fichiers légèrement trompeurs, et vérifiez les réponses serveur. Ce sont des heures gagnées plus tard.
Mettre en place une journalisation et savoir réagir
La sécurité ne se résume pas à empêcher. Elle inclut aussi la capacité à repérer, diagnostiquer, puis corriger.
Même si vous utilisez un plugin, assurez-vous que vous comprenez où vont les logs. Un jour, vous aurez une alerte, et vous devrez agir vite. Si les logs sont inaccessibles, ou si leur conservation est trop courte, vous perdrez la trace utile.
Un bon hardening inclut aussi un canal de réaction. Par exemple, une procédure simple pour:
- couper l’accès admin si vous suspectez une compromission, basculer en maintenance, vérifier l’intégrité des fichiers modifiés, réinitialiser les comptes et les clés si nécessaire, et restaurer une sauvegarde si l’infection est confirmée.
Je préfère des procédures courtes et testées, plutôt qu’un grand document que personne n’a lu. La différence se voit quand ça arrive vraiment.
Procédure de réponse rapide (à adapter à votre contexte)
En pratique, voici un scénario minimal qui évite les décisions prises trop tard:
Activer un mode maintenance ou bloquer l’accès admin de façon temporaire Vérifier les modifications récentes (fichiers, plugins, thèmes, comptes) Changer les identifiants et clés d’accès concernés (au minimum admin et secrets) Restaurer depuis une sauvegarde propre si des éléments sont compromis Corriger la cause racine, puis rouvrir le site et surveillerRenforcer le périmètre serveur, car WordPress ne vit pas seul
WordPress s’exécute sur un serveur, et votre sécurité dépend aussi de ce qui se passe avant lui. Un bon hardening passe donc par des couches externes, comme le pare-feu applicatif, la limitation d’accès au niveau HTTP, la désactivation des services inutiles, et la configuration des permissions système.
Sans entrer dans des recettes universelles (chaque hébergeur a ses pratiques), l’idée est la même: réduire ce qui peut atteindre WordPress sans contrôle. Si vous avez un reverse proxy ou un WAF, exploitez-le. Il peut amortir les attaques de type brute force, ou filtrer certaines patterns d’URL.
Côté serveur, surveillez aussi:
- l’accessibilité des dossiers sensibles, la configuration PHP (version, modules inutiles, gestion des erreurs), et les limites de ressources (qui évitent des dénis de service et des comportements anormaux).
Une remarque issue d’expérience: les sites “propres” côté WordPress peuvent être compromis via une mauvaise configuration PHP, ou via des fichiers uploadés et exécutés par erreur. Hardener WordPress sans regarder l’exécution serveur, c’est comme verrouiller une porte tout en laissant une fenêtre ouverte.
Nettoyer et contrôler la surface d’attaque WordPress
On revient à une logique de fond: tout ce qui est installé est une surface d’attaque. Donc, l’une des actions les plus efficaces est de réduire l’empreinte.
Faites un inventaire, même rapide. Regardez ce qui tourne vraiment: plugins actifs, modules liés aux thèmes, intégrations externes. Les plugins “utiles” sont ceux qui résolvent un besoin clair et maintenu. Les autres sont des candidats au retrait.
L’autre point important est l’accès au backend. Si vous avez plusieurs rôles, évitez l’accumulation d’administrateurs par confort. Pour une équipe réduite, vous pouvez aussi ajouter une gouvernance: une validation interne avant l’installation de plugins, un suivi des changements, et un calendrier de maintenance.
Cette discipline réduit le risque d’ajouter un composant fragile sans vous en rendre compte. Elle aide aussi lors de la réponse à incident, car vous savez quoi vérifier en premier.
Les pièges fréquents pendant le hardening
Le hardening n’est pas seulement une liste d’actions, c’est aussi la gestion des effets de bord. Les erreurs les plus fréquentes viennent de deux sources: casser l’accès légitime, ou se créer une fausse impression de sécurité.
Première catégorie: verrouiller trop fort. Une limitation de brute force trop agressive peut bloquer vos propres accès, ou frustrer des utilisateurs en cas d’erreurs réseau. Je l’ai vécu sur un projet e-commerce: quelques vagues de blocage ont suffi à déclencher des tickets, puis à pousser l’équipe à assouplir sans comprendre. Le résultat: perte de contrôle et attaque qui passe.
Deuxième catégorie: croire qu’un plugin “fait tout”. Certains plugins sécurisent bien des aspects, mais d’autres doublonnent ou interagissent mal avec un cache, un CDN, ou un reverse proxy. On termine avec des règles contradictoires, des redirections en boucle, ou des erreurs sur le login.
La règle pratique est de procéder par étapes, et de tester. Une modification à la fois, ou par lots raisonnables, avec une vérification après chaque étape. Une sécurité solide, c’est une sécurité qui reste stable dans le temps.
Où commencer si vous reprenez un site existant
Si vous héritez d’un WordPress déjà en production, votre ordre de travail peut être différent de celui d’une installation neuve. L’enjeu est de stabiliser vite sans casser.
Je recommande généralement de débuter par ce qui a le plus d’impact immédiat, et le moins d’effets de bord:
- mises à jour WordPress core et suppression des plugins inutiles, révision des comptes et des rôles, durcissement du login, notamment la gestion des tentatives et la journalisation, puis vérification des uploads et de l’exécution côté serveur.
Ensuite seulement, vous passez aux optimisations plus “fines”: durcissements applicatifs supplémentaires, durcissement avancé du serveur, et règles spécifiques à votre architecture.
Vous pouvez aussi coupler le hardening à une mesure de performance indirecte. Par exemple, réduire la charge et améliorer la stabilité peut réduire la fenêtre d’attaque. Ça ne remplace pas la sécurité, mais ça rend l’environnement plus robuste.
Pour rester durable: gouvernance, maintenance et tests
Un hardening réussi ne s’arrête pas au jour 1. Il faut une cadence. Sans cadence, vous revenez vite au point de départ, parce que les plugins s’accumulent, les mises à jour sont oubliées, et des comptes sont créés “pour dépanner”.
Mettez en place un rythme réaliste: une revue mensuelle légère des plugins, une mise à jour régulière (au moins quand des versions corrigent des problèmes), et un contrôle trimestriel des comptes et des rôles.
Côté tests, gardez un minimum d’habitudes. Avant une mise à jour importante, validez sur staging si possible. Si vous ne pouvez pas, testez en production sur un chemin réduit: login, pages critiques, formulaire, et téléchargement de fichiers si vous en avez. Les surprises arrivent rarement sur la page la plus visitée, elles arrivent sur un écran moins utilisé que personne ne vérifie.
Le hardening de WordPress, ce n’est pas un rituel isolé. C’est une manière de gérer un site comme un produit: des accès contrôlés, du code maintenu, une surface d’attaque réduite, et une capacité à détecter et réagir. Commencez par les fondations, avancez par étapes, documentez vos décisions. Vous aurez des résultats concrets, et un site plus résilient face aux tentatives récurrentes, celles qui finissent presque toujours par exploiter ce qui est le plus négligé.