WordPress est solide, mais il attire toujours les mêmes types de menaces : comptes pris au piège, plugins non maintenus, formulaires exposés, thèmes trop permissifs, mauvaises configurations côté serveur. Le résultat est rarement spectaculaire au début. Le plus souvent, ça commence par un détail banal, puis par une “petite” permission, et quand on s’en rend compte, on passe de la maintenance à l’incendie.
Je travaille sur des sites variés, de la vitrine au blog éditorial, et j’ai vu un schéma revenir sans cesse. Les attaques réussies ne sont pas toujours les plus techniques. Elles profitent de réglages oubliés, d’extensions laissées en place, ou de configurations de sécurité qui ne correspondent pas à l’usage réel du site. La bonne nouvelle, c’est que la plupart des risques se réduisent avec des réglages concrets. Ce n’est pas glamour, mais c’est efficace.
Voici 20 réglages que je considère comme indispensables pour renforcer la sécurité de WordPress, réduire les points d’entrée et rendre l’exploitation plus coûteuse pour un attaquant. L’objectif n’est pas de tout verrouiller au point de casser le site, c’est de viser un compromis raisonnable, aligné sur votre niveau de tolérance au risque et sur vos contraintes de production.
1) Mettez à jour WordPress, le thème et les plugins, sans attendre
Les mises à jour sont le premier bouclier. Les failles n’ont pas besoin d’être “récentes” pour être exploitées, elles sont souvent automatisées dès qu’elles sont connues. Sur des sites maintenus, l’attaque doit viser une version précise. Sur des sites figés, l’attaquant a juste à suivre une liste.
Je privilégie une routine simple : WordPress et les plugins critiques d’abord, puis le reste. Oui, il faut tester. Mais retarder une mise à jour parce qu’on manque de temps finit souvent par coûter plus cher que le test.
2) Supprimez les plugins et thèmes inutilisés, pas seulement “désactivez”
Désactiver ne suffit pas. Si un plugin est toujours présent dans l’arborescence, il peut parfois être ciblé d’une manière ou d’une autre, ou rester une surface d’attaque liée à des fichiers, à des endpoints ou à des configurations résiduelles.
Une règle pratique : si vous n’utilisez pas un plugin depuis plusieurs mois, vous n’avez pas besoin qu’il reste installé. Pour les thèmes, c’est pareil. Gardez un thème actif et un thème de remplacement propre, le reste peut disparaître.
3) Renforcez la stratégie de mots de passe
Les attaques par vol de session et par mot de passe sont fréquentes, surtout sur les sites avec des identifiants réutilisés. Le réglage central, c’est la qualité des mots de passe et la limitation des essais.
Sur WordPress, vous pouvez aussi imposer de meilleures politiques avec des réglages côté utilisateur via vos pratiques, ou via un plugin spécialisé. Le point important, c’est la combinaison : mots de passe solides, pas de réutilisation, et blocage ou ralentissement en cas de tentatives suspectes.
4) Activez l’authentification à deux facteurs (2FA)
Le 2FA change la donne quand un mot de passe fuit. Même si votre base utilisateurs est “petite”, les fuites arrivent. Un lien de réinitialisation peut être intercepté, un mot de passe peut être deviné, ou la connexion peut être brute forcée.
Avec 2FA, un attaquant se heurte à une deuxième preuve. Le risque ne disparaît pas, mais il recule nettement. Le trade-off est clair : gérer les appareils de secours et éviter de verrouiller un compte si quelqu’un perd son téléphone. À anticiper dès le départ.
5) Limitez l’accès au panneau d’administration
Vous pouvez réduire la surface de WordPress en contrôlant qui accède au formulaire de connexion et aux pages d’administration. Cela peut se faire via des règles serveur, des restrictions IP, ou des protections “pare-feu” gérées par un pare-feu applicatif.
Je recommande de penser “modèle de trafic réel”. Si votre équipe travaille depuis quelques pays, quelques plages horaires ou un réseau d’entreprise, il est souvent possible d’encadrer l’accès. Si vous avez des collaborateurs internationaux, la logique change, mais vous gagnez toujours à ralentir et surveiller.
6) Protégez l’accès en limitant le nombre de tentatives
La brutalisation de connexion est un classique. Le réglage qui compte n’est pas seulement “bloquer”, c’est aussi “ralentir intelligemment”. Si votre configuration bloque trop agressivement, vous risquez d’impacter des utilisateurs légitimes, notamment avec des outils de navigation, des proxys d’entreprise ou des connexions instables.
Mon conseil : configurez une limite de tentatives raisonnable, combinez avec un mécanisme de détection (même basique), et vérifiez les logs pendant les premières semaines.
7) Configurez correctement les rôles et les permissions des utilisateurs
La plupart des incidents “métier” ne viennent pas d’un exploit. Ils viennent de droits trop larges : un compte éditeur qui peut faire trop, un auteur qui peut installer des extensions, ou un compte administrateur partagé entre plusieurs personnes.
Sur WordPress, les rôles sont un outil. Utilisez-les comme un contrat de confiance minimal. Les comptes doivent correspondre à un besoin réel. Retirez ce qui n’est pas nécessaire.
8) Supprimez les comptes anciens et les comptes “fantômes”
Quand une équipe change, les accès ne suivent pas toujours. Un ancien rédacteur conserve un compte, un prestataire a encore un accès, un compte de test n’a jamais été désactivé.
Sur les sites WordPress, c’est l’un des gains les plus rapides : listez les comptes, identifiez ce qui n’a plus d’utilité, supprimez ou rétrogradez. Je fais ce ménage à intervalles réguliers, et après chaque mission d’un prestataire externe.
9) Renforcez la sécurité des formulaires de connexion et de réinitialisation
Les formulaires de connexion et la récupération de mot de passe sont des points sensibles. Même sans “exploiter” une faille, un attaquant peut provoquer une avalanche de requêtes, ou tenter des scénarios d’énumération.
Le réglage à viser : limiter le spam, réduire l’information renvoyée par le serveur et protéger contre les tentatives répétées. Ici aussi, les mécanismes automatiques via filtrage applicatif et rate limiting font souvent le travail, à condition de vérifier l’impact sur les vrais utilisateurs.
10) Désactivez l’édition de fichiers depuis WordPress
WordPress peut proposer l’édition de fichiers depuis l’interface. Pour la sécurité, beaucoup d’équipes préfèrent la désactiver. Cela limite un scénario où un attaquant obtient un accès et tente de modifier des fichiers directement via l’admin.
Le point délicat, c’est l’exploitation légitime. Si vous utilisez réellement l’édition depuis l’interface, vous avez une dépendance. Dans ce cas, mieux vaut migrer vers un flux de modification contrôlé (FTP, Git, déploiement) plutôt que de garder cette porte ouverte.
11) Désactivez la liste des répertoires quand c’est possible
Les attaques cherchent souvent à “cartographier” un site. Si le serveur affiche des répertoires vides ou certains chemins, l’attaquant gagne du temps.
Ce réglage est généralement côté serveur (permissions, configuration Apache ou Nginx). Si vous gérez votre stack, vérifiez qu’il n’y a pas de listing accessible.
12) Vérifiez et durcissez les permissions de fichiers et dossiers
Des permissions trop permissives facilitent les modifications non autorisées, notamment après un compromis partiel. À l’inverse, des permissions trop strictes peuvent casser l’installation, les mises à jour, ou certains plugins.
Le bon réflexe : utiliser une base saine fournie par votre hébergeur et ne pas “bidouiller” à l’aveugle. Quand il faut changer, faites-le avec une logique claire et gardez une trace, surtout sur les environnements de production.
13) Assurez un SSL valide et redirigez toutes les pages en HTTPS
Sans HTTPS, vous exposez les échanges et vous facilitez certaines formes d’attaque. Même si WordPress gère une partie de la sécurité, c’est le socle réseau qui compte.
Vérifiez que :
- les redirections HTTP vers HTTPS fonctionnent partout, les cookies sont marqués correctement, et que votre configuration ne laisse pas des sous-domaines en clair.
C’est souvent plus simple quand vous utilisez un hébergeur et un proxy “bien réglés”, mais il faut contrôler.
14) Ajoutez des en-têtes de sécurité (CSP, X-Frame-Options, etc.)
Les en-têtes HTTP ne remplacent pas la correction des failles, mais elles compliquent la vie aux attaquants. Selon le stack, on peut améliorer la protection contre le clickjacking, certains XSS, ou le chargement de ressources non autorisées.
Attention pratique : une Content Security Policy trop agressive peut casser des scripts de tracking, des lecteurs vidéo, des widgets, ou des intégrations. Je conseille d’y aller par étapes, en observant le comportement du site et les erreurs de navigateur.
15) Réduisez l’exposition du contenu et des métadonnées d’erreur
Les erreurs détaillées, en mode debug, donnent des informations utiles à l’attaquant. Les messages trop bavards peuvent révéler le chemin d’un fichier, le type d’exception, ou des détails sur le moteur.
Le bon réflexe : en production, debug désactivé, journalisation contrôlée, et un niveau de détail qui reste “humain” pour votre équipe, pas “précis” pour un attaquant.
16) Mettez un WAF ou un filtrage applicatif en place
Un pare-feu applicatif (WAF) peut stopper une grande partie du bruit : bots, tentatives d’exploit automatisées, scans récurrents. C’est souvent l’un des gains les plus visibles, surtout quand votre site reçoit peu de trafic humain.
Mais il y a un piège : un WAF mal paramétré peut bloquer des requêtes légitimes, notamment si vous utilisez des formulaires personnalisés, des API ou des plugins qui génèrent des requêtes inhabituelles.
Je privilégie un déploiement progressif, avec une surveillance des logs et une liste d’exceptions propre.
17) Activez une sauvegarde régulière et testez la restauration
La sauvegarde n’est pas de la sécurité au sens strict, mais c’est la différence entre “on récupère” et “on repart de zéro”. Et un backup non restaurable ne sert à rien. J’insiste : testez la restauration sur un environnement de préproduction, même si c’est une fois tous les mois ou après une grosse mise à jour.
Pour réduire le risque, je recommande aussi de garder une stratégie de rétention claire. En cas d’incident, vous voulez remonter à un état sain sans tomber trop loin.
18) Surveillez l’intégrité des fichiers et les changements
Quand un site est compromis, les attaquants laissent souvent des modifications persistantes : fichiers ajoutés, scripts dans des emplacements inattendus, variations dans le thème ou dans des fichiers de configuration.
Une surveillance d’intégrité vous aide à détecter des écarts. Cela ne garantit pas une réponse instantanée, mais ça raccourcit le temps entre “quelque chose ne va pas” et “on a identifié la cause”.
19) Installez une protection anti-spam et antiphishing, surtout sur les formulaires
Le spam n’est pas juste une nuisance, c’est aussi une porte. Des formulaires mal protégés peuvent être utilisés pour injecter du contenu malveillant, inonder le site, ou servir de vecteur pour des tentatives de contournement.
Un bon anti-spam combine plusieurs approches. Souvent, les réglages de base suffisent. Parfois, il faut adapter selon vos formulaires, votre thème et les intégrations.
Et si votre site est utilisé pour des demandes commerciales, gardez un œil sur les faux positifs. Une protection trop stricte finit par faire perdre des opportunités, et les gens contournent.
20) Vérifiez la sécurité de votre serveur, pas seulement WordPress
Beaucoup de “problèmes WordPress” viennent en réalité du serveur : versions PHP trop anciennes, répertoires accessibles, mauvaise configuration du répertoire uploads, absence de limitation de ressources, journaux incomplets.
Si vous n’avez pas la main, discutez avec votre hébergeur. Demandez ce qui est activé côté WAF, limitation de connexion, support de mises à jour, gestion de logs et pratiques de durcissement.
Cette couche est souvent là où le gain est le plus simple et le plus robuste.
Un mini plan de durcissement (concret, sans prise de tête)
Je ne vais pas vous demander de “tout refaire”. Commencez par le plus rentable, celui qui réduit le risque sans casser la production. Voici l’ordre que je suis le plus souvent sur des sites déjà en activité :
- Mettre à jour WordPress, thèmes et plugins prioritaires, puis lancer un test rapide (front et back) Supprimer les extensions et thèmes inutilisés Activer la 2FA pour les comptes à accès élevé Désactiver l’édition de fichiers depuis WordPress et durcir les droits Vérifier que HTTPS est partout et que les cookies et redirections sont cohérents
C’est un ensemble qui combine correction, réduction de surface d’attaque et contrôle d’accès. Une bonne protection site WordPress ne vient pas d’un seul bouton, elle vient de la cohérence entre plusieurs réglages.
Les réglages qui piégent, même quand on a “fait le travail”
Quand on renforce WordPress, on a souvent un angle mort : ce qui marche “en théorie”, mais pas en pratique. Voici les pièges que je vois le plus :
Laisser trop de plugins actifs, même s’ils “ne servent à rien” Activer des règles de blocage trop agressives, puis bloquer des utilisateurs légitimes Déployer une CSP trop restrictive et casser des intégrations (analytics, vidéos, widgets) Négliger le test de restauration de sauvegardesCe ne sont pas des erreurs absurdes. Ce sont des choix qui coûtent juste plus tard, quand il est moins simple de revenir en arrière.
Comment prioriser selon votre niveau de risque
Vous n’avez pas le même modèle de menace si vous gérez :
- un site vitrine peu exposé, un blog avec plusieurs auteurs, une boutique ou un site à paiement, un site très public avec un flux constant.
En pratique, je priorise toujours ainsi :
- D’abord, tout ce qui protège les identifiants et empêche l’accès non autorisé (mots de passe, 2FA, limitation de tentatives). Ensuite, tout ce qui réduit la surface d’attaque (suppression des composants inutiles, édition de fichiers, durcissement). Enfin, tout ce qui améliore la détection et la récupération (WAF, intégrité, sauvegardes testées).
Le reste, c’est du perfectionnement. Utile, mais pas utile au même niveau que les bases.
Exemple réel de trajectoire de durcissement
Sur un site éditorial, l’équipe avait mis un plugin de sécurité “générique”, mais elle n’avait pas supprimé les extensions inactives. Les mises à jour étaient “quasi” suivies, sauf un module laissé en place car il “ne gênait pas”. Résultat : beaucoup de tentatives de connexion, plus quelques requêtes inhabituelles vers des chemins d’administration.
On a travaillé dans l’ordre : mise à jour ciblée, suppression des plugins non utilisés, activation 2FA sur les comptes administrateur et éditeur, puis limitation de tentatives et vérification des permissions. Le volume des alertes a chuté en quelques jours. Et surtout, quand on a dû restaurer un ancien export à cause d’une erreur de déploiement, la sauvegarde a été utile immédiatement, parce qu’elle avait été testée avant.
Ce genre de séquence ne fait pas de bruit, mais elle change la trajectoire. On passe de “réagir à chaque alerte” à “maîtriser le risque”.
Vérifications finales à garder sous contrôle
Après vos 20 réglages, il reste une étape souvent négligée : confirmer que tout fonctionne réellement avec votre usage.
Vérifiez, sans paranoïa mais sans complaisance :
- que vos comptes peuvent bien se connecter avec les règles activées, que vos formulaires reçoivent les demandes attendues, que les mises à jour restent possibles, que les outils de surveillance et de sauvegarde produisent des journaux exploitables.
La sécurité, ce n’est pas un état figé. C’est un cycle. Un site WordPress évolue, plugins et thèmes changent, les besoins https://gardewp.fr/securite-wordpress/ métiers aussi. Vos réglages doivent accompagner ces changements.
Si vous voulez, dites-moi votre contexte (nombre d’utilisateurs, présence ou non d’une boutique, hébergeur ou stack, plugins spécifiques, niveau de trafic). Je peux vous proposer un plan de priorisation adapté, toujours dans l’esprit réduction des risques plutôt que listes interminables de “tout activer”.