Le durcissement de WordPress, ce n’est pas une affaire de “tout activer” ou “tout couper”. C’est un travail d’arbitrage entre surface d’attaque, compatibilité applicative, exploitation opérationnelle et capacité de réaction. La méthode CIS (Center for Internet Security) m’a beaucoup servi parce qu’elle pousse à une logique simple: on réduit les risques concrets, on priorise ce qui a le meilleur rapport bénéfice versus effort, et on documente les choix. Ce n’est pas un exercice esthétique, c’est une hygiène de production.
Dans ce billet, je vais parler du durcissement WordPress en m’inspirant des principes CIS: configurer le système au plus près du minimum nécessaire, durcir les accès, limiter les permissions, réduire les services et les vecteurs d’injection, et vérifier par des contrôles reproductibles. Je vais aussi être honnête sur les pièges: WordPress est flexible, donc trop de verrouillage peut casser une intégration, et une “bonne pratique” isolée peut devenir une mauvaise idée dans un environnement particulier.
Comprendre ce que “durcir” veut dire pour WordPress
WordPress se comporte souvent comme une application monolithique, mais en réalité l’exposition vient d’un empilement.
Il y a l’hôte (OS, pile web, TLS, pare-feu), il y a la configuration du serveur (PHP-FPM, Nginx/Apache, permissions des fichiers), il y a les couches applicatives (WordPress, plugins, thèmes, base de données), et il y a le contexte de déploiement (réseaux, accès administrateurs, processus CI/CD, supervision).
Quand on parle de durcissement, les priorités CIS se traduisent généralement par quatre objectifs pratiques:
Réduire la surface d’attaque, en limitant ce qui répond, ce qui écoute, et ce qui peut être atteint. Empêcher ou rendre coûteuse l’escalade de privilèges (par des permissions strictes, une séparation claire, des identifiants gérés proprement). Réduire l’impact d’une compromission (limiter les droits, isoler, segmenter, journaliser et contrôler). Assurer la détection et la réponse (logs exploitables, alertes, contrôles périodiques).Ce cadre change la manière de travailler. Au lieu de “mettre un plugin de sécurité et espérer”, on part d’un inventaire, on mesure, puis on durcit ce qui compte.
L’approche CIS, transposée à WordPress
La méthode CIS est structurée pour des environnements système, mais l’esprit reste valable pour WordPress. On vise des contrôles clairs, des paramètres mesurables, et des actions qui peuvent être répétées.
Dans un durcissement WordPress, les “contrôles” concrets ressemblent à:
- Vérifier que WordPress et ses dépendances sont en versions maîtrisées. Réduire les privilèges du compte applicatif (celui qui parle à la base). S’assurer que l’accès administrateur n’est pas exposé au monde sans garde-fous. Appliquer des limites réseau et des règles de filtrage sur les entrées à risque (login, XML-RPC si non utilisé, uploads). Rationaliser les droits système, notamment autour des répertoires d’uploads et des fichiers de configuration. Mettre en place une posture de journalisation, sans noyer les logs.
L’erreur classique consiste à appliquer des recommandations génériques “au hasard”. Par exemple, activer un verrouillage agressif des comptes ou des règles de firewall peut bloquer des partenaires (CRM, outils de monitoring, intégrations SSO), et désactiver XML-RPC peut casser une synchronisation attendue. La méthode CIS ne vous protège pas de ces effets collatéraux, elle vous oblige plutôt à les anticiper.
Préparer le terrain: inventaire, périmètre et objectifs réalistes
Avant de modifier quoi que ce soit, je commence par trois clarifications qui évitent 80% des problèmes.
D’abord, je définis le périmètre: WordPress “nu” ou WordPress en multisite? En front derrière un reverse proxy? Avec un CDN? Avec un WAF? Sur un VPS, chez un hébergeur managé, ou sur une plateforme Kubernetes? Les réponses orientent les contrôles applicables.
Ensuite, je fais un inventaire des composants réellement en place: versions (PHP, base de données, serveur web), plugins actifs, thèmes actifs, modules d’authentification (LDAP, SSO), rôles d’utilisateurs, et intégrations. Si vous avez 30 plugins dont 10 “invisibles” (builders de page, extensions de formulaires, modules d’optimisation), le durcissement doit commencer par la réduction de la dépendance.
Enfin, je fixe un objectif de stabilité. Dans mon expérience, un durcissement “CIS-like” efficace vise un niveau de risque acceptable, pas zéro risque. Sur un site vitrine, l’exigence ne sera pas la même que sur une boutique en ligne qui traite des paiements.
Durcir l’hôte et la couche web (là où les risques se propagent)
Même si le sujet est WordPress, la plupart des compromissions entrent par la couche web et l’environnement. Une configuration “standard” laisse trop souvent des surfaces inutiles.
Permissions et fichiers: le point de départ
Les premiers incidents que j’ai vus sur WordPress n’étaient pas des failles “magiques”, mais des permissions trop ouvertes. Quand le répertoire des uploads est trop permissif, ou quand des fichiers de configuration sont lisibles, vous facilitez l’attaque, et vous dégradez la capacité à détecter des manipulations.
L’idée pratique: WordPress doit pouvoir lire ce dont il a besoin, écrire dans les répertoires prévus, mais pas “tout”. Les permissions doivent suivre le principe du moindre privilège. Si vous utilisez des conteneurs ou une séparation stricte, c’est encore mieux.
En production, je vérifie aussi:
- que les répertoires de configuration ne sont pas accessibles via le web, que les logs sont en lecture restreinte, que les scripts temporaires et caches n’ont pas de droits larges.
Ce travail semble administratif, mais c’est souvent là que les gains de sécurité sont les plus simples à obtenir.
TLS, en-têtes et politique d’accès
Le chiffrement TLS ne suffit pas, mais il conditionne tout le reste. Une connexion mal configurée rend les sessions plus fragiles et complique le suivi.
Côté reverse proxy ou serveur web, je m’assure aussi que l’accès aux endpoints sensibles est raisonnablement cadré. Par exemple, si vous avez XML-RPC, il ne faut pas le laisser exposé à l’internet brut si vous ne l’utilisez pas. Si vous le réduisez à des plages d’IP connues ou à une authentification stricte via votre reverse proxy, vous faites un pas net dans la réduction de surface.
Les en-têtes de sécurité (CSP, X-Content-Type-Options, etc.) Peuvent aider contre certains scénarios d’injection, mais ils doivent être configurés avec prudence sur WordPress, car thèmes et plugins injectent souvent des scripts. Une CSP trop ambitieuse se transforme rapidement en “briseur de site”.
WordPress et base de données: maîtriser l’exécution et les identifiants
C’est souvent le moment où on veut “forcer” toutes les options WordPress. Je préfère une approche plus chirurgicale: corriger ce qui est directement exploitable.
Compte base de données et principe du moindre privilège
Un schéma simple et efficace consiste à utiliser un compte de base de données dédié à WordPress, avec des privilèges minimaux nécessaires. Si votre utilisateur MySQL peut tout faire sur tout, un défaut applicatif ou une compromission ouvre trop de portes.
En pratique, je cherche:
- un utilisateur dédié par site (ou par environnement), des droits limités au schéma WordPress, des identifiants stockés proprement dans wp-config.php, rotation des mots de passe quand un départ d’équipe ou un changement de prestataire a eu lieu.
Je sais que tout le monde n’a pas cette discipline au départ. Mais c’est un levier solide, surtout quand on combine avec la limitation réseau et des logs applicatifs.
wp-config.php: réduire ce qui fuit
Wp-config.php est le “cerveau”. Si quelqu’un parvient à lire cette configuration, la base de données et parfois des clés de sécurité sont exposées.
Mon réflexe en audit: vérifier que wp-config.php n’est pas téléchargeable, qu’il n’est pas servi par le serveur web, et que sa visibilité est strictement empêchée. C’est un contrôle simple, mais qui se retrouve dans de nombreuses recommandations de durcissement.
Versions et dépendances
WordPress évolue, PHP évolue, et les plugins peuvent devenir une dépendance critique. Le durcissement CIS-like consiste à maintenir un inventaire de versions et à réduire les écarts.
Une règle de bon sens: moins vous avez de vieux composants, moins vous multipliez les inconnues. Mais il y a une réalité terrain: mettre à jour un plugin “critique” peut casser un design, ou modifier une logique d’intégration.
Ce que je fais généralement: je maintiens une fenêtre de mise à jour raisonnable et des tests sur un environnement de préproduction. Je n’essaie pas de “surprendre” la production le lundi matin.
Authentification, comptes et accès administrateur: le cœur du durcissement
Les attaques WordPress les plus fréquentes tournent autour de l’accès: brute force, comptes compromis, sessions volées, tentatives de prise de contrôle.
L’objectif est d’empêcher l’attaquant de progresser et de limiter l’impact si un identifiant fuit.
Renforcer la surface de login
Sur WordPress, la page d’identification est une cible évidente. CIS pousse généralement vers des contrôles robustes: limiter les tentatives, protéger contre l’énumération, et surtout renforcer la difficulté d’attaque.
Plus concrètement, je recommande:
- protéger l’accès à wp-login.php via des mécanismes au niveau reverse proxy ou WAF quand c’est possible, utiliser une authentification forte pour les comptes administrateurs (au minimum un second facteur), empêcher les mots de passe faibles avec une politique réaliste.
Attention aux faux positifs. Un durcissement trop strict sur les limites de tentatives peut bloquer des équipes qui utilisent le même réseau depuis un pays ou un opérateur donné. Je teste toujours dans un contexte proche du réel: mêmes plages IP, mêmes habitudes de navigation.
Déplacer l’axe du risque: limiter les rôles
Sur WordPress, trop de personnes sont “administrateurs”. C’est pratique pour gérer, mais c’est un accélérateur de risque. Le durcissement vise à attribuer le rôle minimum nécessaire.
Un bon repère, ce n’est pas la théorie, c’est la maintenance: si votre équipe a besoin d’éditer des contenus, elle n’a pas forcément besoin d’installer des plugins. Si un prestataire ne gère qu’un formulaire, il n’a pas besoin d’accès complet.
J’ai vu des compromissions où un compte “éditeur” avait quand même été utilisé pour injecter des scripts via un plugin mal configuré. La leçon est simple: l’étendue des rôles doit être cohérente avec vos capacités d’exploitation.
Réduire les vecteurs classiques: uploads, thèmes, plugins et XML-RPC
Une grande partie des risques WordPress vient de la capacité à exécuter du code introduit via extensions, ou via fichiers importés, ou via endpoints souvent oubliés.
XML-RPC: utile parfois, dangereux souvent
XML-RPC est un point connu d’attaque. Si votre usage ne le nécessite pas, le désactiver réduit une classe de requêtes.
Le piège, c’est l’usage indirect. Certains flux, certains connecteurs, certains outils de publication peuvent en dépendre. Dans un audit, je vérifie les intégrations existantes avant de couper. Si ce n’est pas utilisé, je le supprime ou je le restreins au minimum.
Plugins: réduire, vérifier, maîtriser
Les plugins sont le terrain où la sécurité se fragmente. Un plugin mal maintenu peut introduire une vulnérabilité ou simplement élargir la surface via des formulaires, des endpoints, ou une gestion de fichiers trop permissive.
La logique CIS, transposée aux plugins, ressemble à:
- garder uniquement les plugins nécessaires, retirer ceux qui ne servent pas, remplacer ce qui est obsolète, verrouiller la mise à jour et tester les changements.
Quand on rationalise la liste des plugins, le gain est immédiat et mesurable: moins de code exécuté, moins de routes exposées, moins d’interfaces d’administration.
Thèmes: éviter l’inutile et contrôler l’exécution
Les thèmes peuvent injecter scripts et styles. L’objectif n’est pas de “tout interdire”, mais de limiter les modifications hasardeuses.
Dans les audits, je regarde particulièrement:
- les options qui permettent l’injection de code, l’existence de champs qui acceptent du contenu non filtré, la présence de “shortcodes” puissants.
Si votre thème ou un plugin permet l’insertion de code JavaScript par des rôles trop larges, vous créez une porte d’entrée. Le durcissement consiste à recadrer qui peut le faire et dans quel cadre.
Répertoires d’uploads: sécuriser le stockage
Les uploads sont, de fait, la zone la plus dynamique. Même si WordPress filtre, des contenus peuvent contenir des tentatives d’exécution.
Le durcissement consiste à s’assurer que:
- les types autorisés sont raisonnables, l’exécution côté web n’est pas possible dans les répertoires d’uploads, la taille et le rythme d’upload sont contrôlés.
Ce point est très “terrain”. Sur certains hébergeurs, des directives spécifiques sont ignorées ou à ajuster. Je m’assure donc que la configuration réelle correspond à la configuration attendue, en testant concrètement.
Un mini plan d’action, façon CIS, pour un WordPress de production
Je vous propose une séquence de travail que j’utilise en audit. Elle évite le piège de modifier dans le désordre et de ne plus savoir ce qui a changé.
Mettre à jour WordPress et PHP sur un environnement de test, valider plugins et thème. Vérifier permissions des fichiers et que wp-config.php n’est pas accessible via le web. Renforcer l’accès admin, idéalement avec second facteur, et limiter les rôles. Désactiver ou restreindre XML-RPC si non nécessaire, vérifier les intégrations existantes. Mettre en place une journalisation utilisable, avec une rotation et des accès restreints aux logs.Liste 1 (checklist courte)
L’ordre compte, parce que la journalisation et la protection d’accès vous donnent du signal pendant que vous durcissez le reste. Sans logs, vous avancez à l’aveugle.
Durcir sans casser: compromis et effets collatéraux
Le durcissement n’est pas gratuit. Vous payez parfois en complexité, parfois en maintenance, parfois en perte de confort.
Quelques compromis que je rencontre régulièrement:
- Protection brute force: très efficace, mais peut bloquer des utilisateurs légitimes sur une IP partagée, ou créer des frictions avec des comptes qui se renouvellent souvent (SaaS, CRM, intégrations). Désactivation de fonctions: XML-RPC, éditeurs avancés, REST endpoints, ou limitations d’uploads. Couper peut casser une intégration de publication ou un workflow interne. CSP et durcissement navigateur: peut améliorer le profil d’injection, mais sur WordPress, thèmes et plugins injectent souvent du contenu. Un CSP trop strict peut casser des formulaires ou des tracking scripts. Durcissement des permissions: c’est généralement bon, mais si un plugin a besoin d’écrire ailleurs que prévu, vous avez des erreurs difficiles à diagnostiquer.
Ma règle d’or: chaque changement majeur doit être traçable. Que ce soit via un ticket, un commit de configuration, ou une note d’audit, vous voulez pouvoir revenir en arrière sans repartir de zéro.
Contrôles et vérification: prouver que le durcissement tient
Une posture CIS-like n’est pas seulement “configurée”, elle est “vérifiée”. Les contrôles doivent être répétables. Sinon, votre système se dégrade au fil des mises à jour.
Dans WordPress, les vérifications utiles ne sont pas forcément des scans interminables. Elles sont souvent simples, mais ciblées.
Je fais régulièrement:
- un contrôle de versions (WordPress, PHP, base de données), un contrôle des comptes et rôles, un contrôle des plugins actifs (et surtout, de ceux qui ont des accès d’administration), un contrôle des logs d’accès et des erreurs applicatives, des tests de login depuis un environnement “humain” réaliste (pas seulement depuis mon poste).
Je recommande aussi d’organiser une revue périodique. Par exemple, après chaque mise à jour PHP ou après un changement de configuration reverse proxy, vous relancez un mini lot de tests. C’est là que vous attrapez les effets collatéraux.
Supervision, logs et réponse: la partie souvent oubliée
Durcir sans superviser, c’est comme fermer des serrures sans regarder les caméras.
Pour WordPress, un système de logs efficace doit couvrir au moins:
- accès au login et aux endpoints sensibles, erreurs applicatives et fatales, événements d’authentification, changements de configuration côté application quand c’est possible, activité admin quand vous pouvez la capter.
Je préfère une approche “utile” plutôt que “volume”. Des logs illimités génèrent du bruit et font mourir la discipline. Un bon log est un log qui permet de décider: blocage, enquête, restauration, correction.
En réponse à incident, je garde aussi un runbook minimal: quoi vérifier en premier, quels identifiants invalider, comment isoler le site, comment restaurer proprement.
Cas pratiques: ce que j’ai vu fonctionner (et ce qui m’a surpris)
Un cas fréquent: des sites “sécurisés” via un plugin, mais avec un accès admin exposé trop largement. On a des alertes, mais pas de barrières. Quand on applique une restriction d’accès (réseau, authentification forte), la charge des tentatives diminue nettement, et les événements deviennent plus pertinents.
Autre situation: un propriétaire insiste pour désactiver XML-RPC “par principe”, puis découvre que son outil de publication interne s’en servait. La leçon est double. D’abord, il faut connaître les intégrations. Ensuite, quand une fonctionnalité est nécessaire, on la restreint plutôt que de la supprimer.
Le troisième scénario: une équipe durcit les permissions pour “être conforme”, puis un plugin d’import ou un builder de formulaires cesse d’écrire au bon endroit. Résultat, on corrige dans la panique en élargissant trop. Cette fois-là, j’ai réussi à résoudre en alignant précisément les permissions sur les répertoires réellement nécessaires, au lieu d’ouvrir toute l’arborescence.
Pièges courants quand on suit une logique CIS sur WordPress
Je regroupe ici les erreurs que je vois le plus souvent, parce qu’elles viennent d’une interprétation trop mécanique.
- Interpréter une recommandation système comme applicable telle quelle à l’application. WordPress a ses chemins et ses besoins, et les plugins créent des cas d’usage particuliers. Changer trop de choses en même temps. Vous ne saurez pas quoi a cassé, ni quoi a amélioré. Négliger les rôles. Un compte administrateur de trop, c’est une “faille de politique” plus dangereuse qu’un paramètre isolé. Ignorer les mises à jour. Un durcissement n’est pas un état, c’est un processus. Les mises à jour changent parfois l’écosystème.
Le durcissement CIS-like sur WordPress doit rester lisible pour l’équipe. Si personne ne comprend pourquoi un endpoint est restreint, vous reviendrez en arrière à la première friction.
Maintenir le durcissement: cadence et discipline
Le meilleur durcissement du monde s’effiloche avec le temps: plugins abandonnés, comptes qui s’accumulent, environnements de test qui deviennent “un peu” en production, modifications manuelles qui contournent la procédure.
Je conseille d’adopter une cadence simple:
Revue des rôles et des accès, à une fréquence fixe. Revue des plugins et suppression régulière de l’inutile. Mise à jour WordPress et PHP selon une fenêtre planifiée. Test de restauration et vérification des backups. Revalidation après tout changement d’infrastructure (proxy, WAF, règles réseau).Liste 2 (rythme de maintenance minimal)
Si vous avez déjà une discipline CI/CD, utilisez-la pour pousser les configurations durcies. Si vous ne l’avez pas, commencez petit, mais gardez un historique. C’est ce qui rend l’approche CIS tenable dans la durée.
Comment savoir si votre durcissement est “suffisant”
Le “suffisant” n’a pas une valeur universelle. Il dépend de la criticité et de la probabilité d’exploitation. Ce que la méthode CIS encourage, c’est une démarche documentée: vous réduisez des risques concrets et vous gardez un niveau acceptable.
Un indicateur pratique: la qualité de vos journaux et la capacité à expliquer ce que vous avez fait. Si vous ne pouvez pas décrire pourquoi un endpoint est protégé, qui a accès, et quelle est la stratégie de mise à jour, alors https://gardewp.fr/securite-wordpress/ vous êtes en zone floue.
À l’inverse, si vous avez:
- une liste de contrôles appliqués, une méthode de test, une cadence de revue, un plan de retour arrière,
Alors votre durcissement est plus robuste que la simple addition de plugins.
Conclusion implicite, mais utile: CIS n’est pas une recette, c’est une méthode
Durcir WordPress en suivant une logique CIS revient à penser comme un défenseur pragmatique. Vous ne cherchez pas à tout verrouiller, vous cherchez à rendre l’exploitation plus difficile et plus coûteuse, et à limiter l’impact quand quelque chose tourne mal.
Si je devais résumer l’approche en une phrase de terrain: durcissez ce que vous pouvez vérifier, et vérifiez ce que vous durcissez. La sécurité devient alors une compétence d’exploitation, pas un chantier ponctuel.
Si vous voulez, je peux adapter ce guide à votre contexte précis (hébergeur, reverse proxy, présence ou non de multisite, plugins critiques, et niveau d’accessibilité admin). Avec quelques détails, on peut transformer ces principes en contrôles concrets, adaptés sans casser vos intégrations.