Quand on parle de durcissement WordPress, on pense vite aux plugins de sécurité, aux mises à jour, aux mots de passe solides. C’est bien, mais c’est rarement là que la majorité des incidents commence. Dans la pratique, les failles les plus coûteuses viennent d’un hébergement trop permissif, d’une configuration serveur bancale, ou d’un réseau mal segmenté. Un site WordPress peut être parfaitement “à jour” et quand même exposé, parce que la plateforme en dessous ne tient pas son rôle.
J’ai vu des sites prendre des accès via des services non liés au CMS, parce que des ports restaient ouverts, parce que PHP tournait avec des réglages trop généreux, ou parce que le serveur autorisait l’écriture de fichiers là où il ne fallait pas. À l’inverse, quand l’infrastructure est propre, même une erreur applicative se transforme souvent en incident mineur.
Le durcissement, c’est donc un travail de fond. Il s’agit de réduire la surface d’attaque, d’augmenter la friction contre les comportements abusifs, et surtout de rendre l’environnement “tolérant aux erreurs”. On vise un système qui résiste, mais aussi un système qui permet de détecter vite quand quelque chose dérape.
Commencer par le diagnostic, pas par la peur
Avant de “durcir”, il faut comprendre ce que vous avez. Sinon, vous durcissez le mauvais endroit, ou vous cassez un fonctionnement légitime sans le savoir.
Sur un hébergement WordPress, le socle, c’est généralement l’hyperviseur ou la VM, ensuite le système d’exploitation, puis le reverse proxy ou le serveur web, ensuite PHP, et enfin la couche applicative. Chaque couche a ses propres drapeaux, droits, logs, et pièges.
Une démarche réaliste consiste à relever, même rapidement, quatre ensembles d’informations :
- qui a accès en SSH et comment, quel serveur web est utilisé (Nginx, Apache), quelle version de PHP tourne et avec quels paramètres clés, quels services réseau sont exposés sur le serveur.
J’aime aussi vérifier le “par où ça respire”. Si WordPress sort librement vers l’extérieur (pour des mises à jour, du SMTP, des webhooks), ce n’est pas un problème en soi. Mais il faut savoir si le serveur peut joindre n’importe quel domaine, ou si le flux est bridée côté réseau.
Ce diagnostic évite les faux gagnants. Par exemple, renforcer les règles du CMS ne compensera pas un serveur qui autorise l’exécution PHP dans un répertoire de uploads, ou qui expose un panneau d’administration interne sur Internet.
Durcissement WordPress : ce que l’hébergement doit empêcher
WordPress n’a pas besoin de pouvoirs élevés sur le système. Le CMS doit écrire dans quelques répertoires, lire le reste, et exécuter PHP là où c’est prévu. Tout excès de droits est un cadeau aux attaquants, surtout dans les scénarios où ils arrivent à déposer https://gardewp.fr/securite-wordpress/ un fichier (via une faille plugin, une compromission de compte, ou une chaîne d’injection).
Le durcissement WordPress sur serveur vise donc des principes assez concrets.
D’abord, on sépare l’exécution du contenu et la gestion des fichiers. Ensuite, on limite ce qui peut être écrit et par qui. Enfin, on réduit l’exposition des services à Internet à un minimum.
Un point qui revient souvent dans les incidents, c’est l’accès au système de fichiers via des chemins “non intuitifs”. Des attaquants cherchent à récupérer des fichiers de configuration, des logs applicatifs, des sauvegardes, ou des fichiers temporaires. Pour eux, l’objectif n’est pas toujours de “pirater WordPress”, c’est de trouver une information exploitable, puis d’étendre l’accès.
Choisir la bonne granularité de contrôle
Tous les hébergeurs ne se valent pas. Un hébergement mutualisé peut convenir pour démarrer, mais le niveau de contrôle sur les réglages PHP, sur le serveur web, et sur la segmentation réseau est souvent limité. Quand vous cherchez un durcissement WordPress sérieux, vous vous heurtez tôt ou tard à la question suivante : “Est-ce que j’ai la main sur la configuration du serveur ?”
Sur un VPS ou une instance dédiée, vous pouvez appliquer :
- une politique stricte de droits, des règles web server précises, une configuration PHP mieux cadrée, un pare-feu au niveau réseau, une journalisation exploitable.
Sur un service “géré”, vous gagnez du confort, mais il faut vérifier ce que le fournisseur fait réellement, notamment sur la partie PHP et la configuration HTTP. Certains environnements “gérés” bloquent certains réglages. C’est parfois acceptable, tant que les protections existent. Le problème, c’est quand on croit que c’est protégé, alors que ça ne l’est pas.
Je conseille de traiter le durcissement comme un contrat technique : vous devez savoir ce qui est possible, ce qui est figé, et ce qui est monitoré.
Durcir le serveur web (Nginx ou Apache) sans casser le site
La configuration du serveur web est souvent le levier le plus rentable. Dans WordPress, les contenus statiques vivent dans des répertoires précis, et les fichiers applicatifs doivent rester dans leur place. Si vous arrivez à rendre ces frontières invisibles pour un attaquant, vous gagnez énormément.
Sur Nginx, par exemple, on peut :
- empêcher l’accès direct à des fichiers sensibles, limiter certains types de requêtes, contrôler la façon dont les fichiers PHP sont servis, désactiver des comportements dangereux comme l’indexation de répertoires.
Sur Apache, ce sont des directives analogues, selon que vous utilisez mod_php, php-fpm, ou un module. Dans les deux cas, le but est le même : empêcher l’exécution PHP là où ce n’est pas censé exister, et réduire la surface autour des chemins de fichiers.
Un piège classique, c’est d’ajouter “trop de règles”. Par exemple, une règle qui bloque certains patterns dans les URL peut casser des fonctionnalités légitimes, comme des paramètres d’API, des callbacks, ou des endpoints utilisés par un plugin. Le durcissement doit être testé sur un environnement de préproduction. Je l’ai appris en redécouvrant, un matin, que la suppression d’une directive “pour la sécurité” faisait échouer des mises à jour automatiques.
PHP-FPM et les réglages qui font la différence
PHP est l’exécuteur. Ce n’est pas seulement une version récente. Les options de PHP déterminent comment les scripts s’exécutent, comment les erreurs sont gérées, et parfois même ce que l’application peut faire au niveau système.
L’objectif du durcissement côté PHP, c’est de limiter ce qui pourrait transformer une petite erreur en prise de contrôle.
Trois familles de paramètres reviennent dans beaucoup d’exploitations :
La gestion des erreurs et la divulgation d’informations, L’accès au système de fichiers et les fonctions risquées, La capacité à invoquer des opérations externes ou à charger des fichiers arbitraires.Selon votre configuration, certaines fonctions PHP peuvent être désactivées (par exemple des fonctions de type exec, shell_exec, ou encore des fonctions permettant d’inclure des fichiers d’une manière trop permissive). La prudence s’impose, parce que des plugins peuvent en dépendre, surtout des plugins “tout-en-un” de construction, d’optimisation, ou d’import.
Dans un durcissement WordPress mature, on préfère une approche “permissif au début, stricte ensuite” : on surveille ce dont l’application a besoin, on corrige, puis on durcit de manière progressive. Les gains viennent rarement d’un seul changement. Ils viennent de la somme de petits ajustements.
Sur PHP-FPM, la configuration du pool (utilisateur, groupe, permissions de socket, limites de ressources) compte aussi. Un pool trop large en ressources ou mal cloisonné peut être attaqué par déni de service applicatif. Dans ce cas, même sans “hack” au sens classique, l’attaquant obtient ce qu’il veut : indisponibilité.
Exemple de réglages attendus, à adapter selon votre stack
Je ne peux pas vous donner une liste universelle sans risquer de casser des setups, mais l’esprit est constant :
- activer la journalisation côté PHP et côté web server, éviter la divulgation de détails en production, limiter les upload sizes selon vos besoins, s’assurer que les répertoires d’uploads ne sont pas exécutables en PHP.
Pour WordPress, le point critique est presque toujours “uploads”. Les fichiers uploadés peuvent contenir du code si un attaquant trouve une manière d’y déposer du contenu malveillant. Si PHP peut s’y exécuter, le risque devient rapidement majeur. La solution n’est pas seulement “ne pas uploader de PHP”. C’est “empêcher l’exécution PHP dans les répertoires d’uploads”.
Droits système et organisation des fichiers : le durcissement discret
Sur serveur, la sécurité ressemble souvent à de la menuiserie. Si les droits sont mal posés, le reste tient mal.
WordPress, avec ses thèmes, plugins, et médias, fonctionne avec un mix de lecture et écriture. Les répertoires de base ont besoin d’être accessibles en écriture pour certaines opérations (uploads, parfois cache selon la configuration). Mais le code de WordPress et les thèmes doivent rester en lecture pour l’utilisateur applicatif. Les mises à jour doivent se faire avec une procédure contrôlée.
Dans l’idéal, vous séparez :
- l’utilisateur qui exécute le service web ou PHP-FPM, l’utilisateur qui déploie du code, l’utilisateur qui effectue les mises à jour (automatiques ou orchestrées).
Si tout tourne avec le même niveau de droits, vous perdez le bénéfice de la séparation. En pratique, sur des VPS, j’ai vu des incidents où le répertoire wp-content tournait avec des permissions trop permissives. Un simple bug applicatif, ou un plugin compromis, suffisait à étendre l’accès.
Le durcissement ici, c’est de :
- réduire les permissions “writable” au strict nécessaire, vérifier que les droits sur wp-config.php ne sont pas lisibles, contrôler les permissions dans wp-content/uploads, s’assurer que les scripts ne peuvent pas écrire ailleurs.
Réseau et pare-feu : la première ligne de défense
Le pare-feu et la politique réseau sont souvent sous-estimés dans la sécurité WordPress. Pourtant, ils stoppent des classes entières d’attaques, notamment les scans et les tentatives d’accès à des services inattendus.
Si vous ne publiez sur Internet que ce qui est nécessaire (généralement HTTP et HTTPS), vous limitez la découverte. Si en plus SSH n’est exposé qu’à des adresses de confiance (ou via VPN), vous réduisez drastiquement la probabilité d’un incident.
On entend souvent “il y a un pare-feu sur le serveur”. Parfois, c’est vrai, parfois c’est “installé mais pas appliqué”, parfois c’est configuré trop largement. Une règle claire en durcissement WordPress, c’est de vérifier réellement le comportement, pas de se contenter d’une promesse.
Voici une mini check-list utile pour valider que le socle réseau est sain, sans partir dans des configurations compliquées :
- Vérifier quels ports écoutent réellement sur la VM (pas seulement ceux déclarés). Restreindre l’accès SSH à des IP de confiance, ou le supprimer d’Internet via pare-feu ou VPN. Autoriser uniquement 80/443 vers le monde extérieur, sauf besoin explicite. Activer des règles anti-scan basiques et limiter les connexions entrantes. Conserver des logs de pare-feu pour investiguer après incident.
Cette approche évite de se concentrer sur le CMS alors que c’est le serveur qui est “grand ouvert”.
Authentification, accès admin et secrets : le durcissement qui évite les cascades
Une grosse part des attaques sur WordPress ne commencent pas par une exploitation technique. Elles commencent par une compromission de compte, un mot de passe réutilisé, ou une exposition d’identifiants.
Le durcissement côté serveur doit donc soutenir un modèle d’accès sûr. Si votre admin panel d’un hosting est accessible en clair, si l’auth SSH est faible, ou si des secrets traînent dans des fichiers accessibles, vous offrez une voie rapide.
Sur le plan pratique, je regarde toujours :
- la façon dont l’accès SSH est géré, si le provisioning et le déploiement utilisent des clés et non des mots de passe, la protection des clés et l’absence de secrets dans les dépôts, les politiques MFA quand elles existent.
Pour WordPress lui-même, il y a des réglages utiles, comme la limitation de tentatives de connexion, l’usage de CAPTCHA sur les formulaires sensibles, et la mise en place d’un WAF ou de protections au niveau reverse proxy. Mais encore une fois, ce n’est pas la seule brique. Le durcissement serveur sert à empêcher l’attaquant d’aller plus loin une fois qu’il a trouvé une entrée.
Journalisation et observabilité : savoir avant de subir
Un serveur durci sans capacité d’observer, c’est un château fort sans fenêtres. Vous aurez peut-être l’impression d’être en sécurité, jusqu’au jour où vous découvrez l’incident trop tard.
La journalisation doit couvrir :
- le trafic web (requêtes, codes d’erreur significatifs), les logs applicatifs WordPress (au moins les erreurs), les logs PHP et PHP-FPM, les événements d’accès système (SSH, sudo, changements de fichiers quand c’est possible), les événements de pare-feu.
Le point le plus important est la cohérence. Si les logs existent mais ne sont pas corrélés, vous perdez du temps à reconstituer le puzzle.
J’ai un “rituel” assez simple : après durcissement, je génère volontairement quelques erreurs contrôlées (par exemple une requête 404, une tentative de chargement invalide, un scénario d’échec d’auth). Ensuite, je vérifie que je retrouve l’événement dans les bons logs, au bon endroit, avec suffisamment de contexte. Ce test me dit si la surveillance est réelle ou seulement décorative.
Sécuriser les mises à jour et le déploiement : le talon d’Achille
Beaucoup de sites sont sécurisés “à l’instant T”, puis déstabilisés au moment des mises à jour. Un plugin mis à jour qui change les répertoires, une configuration de cache modifiée, un nouveau chemin d’exécution PHP, et soudain les protections ne s’appliquent plus comme prévu.
Le durcissement WordPress implique une discipline de déploiement. Le plus efficace, c’est un workflow de test :
- une pré-production identique, des mises à jour testées, un rollback plan si quelque chose casse, des permissions qui n’augmentent pas au fil des modifications.
Dans un environnement professionnel, on évite que tout le monde touche à tout. Les rôles doivent être clairs : ceux qui déploient ne sont pas ceux qui naviguent librement dans la machine. Ceux qui modifient la configuration réseau ne devraient pas être ceux qui installent des plugins.
Cette séparation réduit les erreurs humaines, et les erreurs humaines sont la cause la plus fréquente d’un durcissement “qui s’envole” après quelques semaines.
DDoS et disponibilité : sécurité ne veut pas dire seulement “intrusion”
Il y a une autre dimension du durcissement WordPress : l’endurance. Un site peut survivre à une intrusion ou à une tentative d’exploitation, et quand même être “cassé” par un déni de service, même basique.
Sur le serveur, vous pouvez :
- limiter les tailles de requêtes, mettre en place une protection au niveau reverse proxy (rate limiting, gestion des connexions), utiliser des timeouts adaptés, surveiller les pics CPU/RAM liés aux requêtes PHP.
Le bon réglage dépend de votre trafic et de votre architecture. Sur un site e-commerce, les pics sont parfois naturels. Sur un site vitrine, un pic CPU peut signaler un spam d’exécution PHP ou une boucle involontaire. Il faut donc calibrer, pas appliquer une règle standard.
Ce calibrage vient d’un suivi, pas d’un article. Là encore, l’observabilité fait la différence entre une protection efficace et une mesure qui pénalise vos utilisateurs.
Durcissement WordPress : limites, compromis et décisions à prendre
On a tendance à vouloir “tout bloquer”. En durcissement WordPress, ça marche rarement dans une réalité d’écosystème WordPress.
Les compromis typiques :
- Bloquer trop de types de fichiers d’upload peut empêcher des fonctionnalités légitimes (PDF, CSV, images, formats spécifiques). Désactiver des fonctions PHP peut casser un plugin “SEO”, un outil d’import, ou un module de génération. Rendre les accès trop stricts peut bloquer des bots légitimes, des services de monitoring, ou des intégrations (webhooks, API externes). Durcir les rules HTTP peut casser des redirections, des endpoints ou des requêtes de cache.
Le bon durcissement, c’est celui qui réduit le risque sans créer un terrain d’incidents opérationnels. Si vos protections demandent six interventions manuelles par semaine, elles seront contournées. Et quand elles seront contournées, elles ne protègeront plus.
Une méthode que j’ai utilisée pour éviter ce scénario consiste à introduire les changements par couches, en commençant par les règles qui sont “à faible risque” :
- restrictions d’exécution PHP sur les répertoires non prévus, contrôle des accès aux fichiers sensibles, configuration d’erreurs plus sûre, pare-feu et réduction de l’exposition réseau.
Ensuite seulement, on s’attaque aux réglages les plus intrusifs. Cela réduit les surprises.
Cas pratique : trois erreurs fréquentes que j’ai vues sur des WordPress “presque corrects”
Sans raconter des histoires nominatives, il y a trois patterns qui reviennent quand on examine des serveurs “déjà configurés”.
Premier pattern : l’environnement a un pare-feu, mais il ne filtre pas vraiment l’inbound. Résultat, des logs montrent des centaines de requêtes d’exploration sur des chemins évidents, puis une charge CPU anormale. Le site n’est pas forcément hacké, mais il souffre.
Deuxième pattern : l’exécution PHP est correctement limitée sur public_html, mais la configuration autorise PHP dans un sous-répertoire de stockage. Sur WordPress, selon comment le cache et certains plugins stockent les fichiers, on peut se retrouver avec une surprise. Ce n’est pas “la faute” du CMS. C’est le serveur qui a laissé une porte.
Troisième pattern : les mots de passe et la double authentification existent, mais les accès au serveur restent trop ouverts. Un attaquant n’a pas besoin de casser une application, il tente juste des connexions. Dans les journaux, on voit passer des tentatives répétées sur des horaires cohérents. Une fois un compte compromis, le reste suit.
Ce que j’attends d’un durcissement WordPress bien mené, c’est que ces trois problèmes soient traités ensemble, pas séparément.
Comment planifier vos prochaines étapes de durcissement
Si vous devez prioriser, je recommande de raisonner “impact sur surface d’attaque” et “probabilité d’erreur”. Les changements qui réduisent l’exposition réseau et empêchent l’exécution PHP au mauvais endroit sont généralement très rentables.
Une autre mini check-list, plus orientée “action” sur le serveur, peut aider à cadrer le travail d’équipe :
- Vérifier que les répertoires d’uploads et de cache ne peuvent pas exécuter du PHP. Contrôler les permissions des fichiers sensibles, surtout wp-config.php. Mettre en place un pare-feu effectif et restreindre l’accès SSH. Vérifier la configuration PHP-FPM, notamment les limites et la journalisation. Confirmer que les logs web et PHP sont activés et exploitables en cas d’incident.
L’idéal est de documenter chaque changement. Une sécurité durable est aussi une sécurité maintenable. Quand quelqu’un doit reprendre un serveur dans six mois, il doit comprendre pourquoi telle règle existe, et quels effets elle a eu sur le site.
Vérifications finales avant mise en production
Après durcissement WordPress, je fais toujours une validation pragmatique. Pas une “validation” théorique.
Je teste :
- chargement normal du site, connexion à l’administration, envoi de formulaires (si présents), uploads classiques (images, médias attendus), génération de pages dynamiques, fonctionnement de cache et de minification si vous l’utilisez, comportement des redirections et des URL (notamment pour WordPress multisite si c’est votre cas).
Puis je regarde les logs quelques minutes après les tests. Un serveur bien durci donne des erreurs propres, et des journaux cohérents. Un serveur mal durci se manifeste par une pluie d’erreurs 500, des warnings PHP répétés, ou des requêtes rejetées en masse.
Ce moment de vérification est celui qui évite les “sécurisations” qui empirent tout. Et surtout, il transforme votre durcissement WordPress en un processus, pas en un événement ponctuel.
Un dernier mot sur l’entretien
Le durcissement n’est pas un projet à finir, c’est un niveau de service. Les versions évoluent, les plugins changent, les comportements réseau aussi. Un serveur sécurisé aujourd’hui peut redevenir vulnérable si une mise à jour modifie un chemin d’exécution, si un plugin installe un composant avec de nouveaux droits, ou si une règle pare-feu est “assouplie” par urgence.
La bonne routine, c’est un cycle régulier : mises à jour, revue des logs, vérification rapide des règles essentielles, et re-tests sur un environnement de préproduction.
Sécuriser l’hébergement et la configuration serveur, c’est ce qui donne à WordPress une base solide. Et quand la base tient, les protections applicatives deviennent beaucoup plus efficaces, parce que l’attaquant doit franchir plusieurs barrières, dans le bon ordre, avec des chances décroissantes.
Si vous voulez, décrivez votre stack (Nginx ou Apache, version de PHP, hébergement mutualisé ou VPS, et si PHP-FPM est utilisé). Je peux vous proposer une grille de durcissement plus ciblée, adaptée à vos contraintes, sans vous pousser vers des réglages qui casseraient votre site.