WordPress est rarement le problème à lui seul. La plupart des incidents commencent ailleurs: une mauvaise configuration du serveur, des permissions trop larges, une surface d’attaque laissée ouverte, ou une règle de sécurité qui s’applique “sur le papier” mais pas dans la pratique. Durcir Apache ou Nginx, c’est agir au bon endroit, sans dépendre uniquement d’un plugin.
Dans ce billet, je me concentre sur la couche serveur: ce que vous pouvez verrouiller proprement, comment éviter les pièges courants, et quels compromis accepter selon le type de site. L’objectif n’est pas de “tout fermer”. C’est de réduire les chemins d’attaque utiles, tout en gardant WordPress fonctionnel.
Le serveur comme premier rempart
Quand quelqu’un tente d’exploiter un site WordPress, il cherche en général trois choses: des informations (versions, chemins, fichiers accessibles), un moyen d’exécuter du code (upload, scripts, interprétation inattendue), ou une persistance (accès à des zones d’administration, tableaux de bord, fichiers de configuration).
Le serveur peut aider avant même d’arriver à WordPress. Une configuration bien durcie:
- limite les fichiers lisibles, supprime des comportements dangereux par défaut, réduit l’exposition de chemins internes, et améliore la manière dont le trafic est filtré.
À l’inverse, une configuration trop “souple” crée des angles morts. J’ai vu des sites où la sécurité semblait assurée parce que WordPress et les plugins étaient à jour, alors que le serveur laissait encore des répertoires exposés, ou que le traitement PHP pouvait s’activer dans des endroits non prévus.
Préparer le terrain: comprendre votre architecture
Avant de toucher à Apache ou Nginx, prenez cinq minutes pour clarifier votre contexte, car les recommandations ne se valent pas partout.
Vous utilisez probablement l’une de ces architectures:
- WordPress “classique” avec PHP-FPM ou mod_php. WordPress derrière un reverse proxy (Nginx devant Apache, ou Nginx devant PHP-FPM). Un hébergement mutualisé, où l’accès à la config complète est limité. Un environnement conteneurisé (Docker, Kubernetes), avec des règles de routage internes.
Selon le cas, certains durcissements seront impossibles, ou au contraire indispensables. Sur mutualisé, vous jouez surtout sur les fichiers .htaccess ou les paramètres fournis. Sur serveur dédié, vous pouvez centraliser davantage dans la config principale.
Un détail pratique: si vous ne savez pas exactement où s’exécute PHP (mod_php, PHP-FPM, FastCGI), vous pouvez casser le site en appliquant une règle “logique” mais mal ciblée. Si vous avez accès à des logs, c’est votre meilleur ami.
Durcir côté Apache: réduire l’exposition et verrouiller l’exécution
Apache est encore très fréquent pour WordPress. Son modèle de configuration est puissant, mais aussi propice aux oublis. L’idée, c’est d’aligner Apache avec un usage WordPress standard.
Bloquer la lecture de fichiers sensibles
On oublie souvent qu’un serveur web peut exposer plus que ce qu’on croit. Les dossiers et fichiers “techniques” ne sont pas tous protégés par défaut. Sur Apache, les protections doivent couvrir des chemins comme:
- fichiers de configuration, backups, journaux, fichiers de contrôle d’applications.
Dans la pratique, beaucoup de protections efficaces se font avec des règles génériques, complétées par une gestion stricte de l’accès aux répertoires.
S’assurer que PHP ne s’exécute que là où vous le souhaitez
Le point sensible, c’est l’interprétation. Si PHP est autorisé dans des emplacements non prévus, vous augmentez la surface d’attaque. Sur un site WordPress, vous voulez que PHP s’exécute sur les scripts attendus, généralement .php dans les répertoires applicatifs, et pas via des déclencheurs exotiques (certains patterns de nommage ou des extensions détournées selon le contexte).
Un exemple concret: certains serveurs acceptent des exécutions dans des types non standards si la configuration “mime” ou les handlers sont mal réglés. Ce n’est pas un bug de WordPress. C’est un comportement serveur.
Désactiver l’affichage des informations inutiles
D’expérience, quand un attaquant arrive, il cherche à confirmer des hypothèses rapidement. Les pages d’erreur trop bavardes, les bannières, et certaines informations de diagnostic peuvent accélérer une campagne.
Réduire l’information exposée n’empêche pas le dépannage. Il faut juste séparer “ce que voit l’utilisateur” de “ce que consigne le serveur”. Vous gardez les logs détaillés, mais vous évitez de renvoyer des détails sensibles à l’extérieur.
Forcer une hygiène réseau et une gestion stricte des requêtes
Apache peut aussi être configuré pour:
- rejeter des requêtes invalides, limiter certains comportements de routage, contrôler des en-têtes, et mieux gérer les règles de sécurité (par exemple via des modules et des paramètres de timeout).
Sur ce sujet, l’équilibre est délicat: trop de durcissement peut provoquer des erreurs inattendues chez certains navigateurs ou derrière certains proxys. Ici, la règle d’or reste la même: tester sur un environnement proche de la production, puis mesurer dans les logs.
Durcir côté Nginx: gagner en clarté, éviter les pièges FastCGI
Nginx est souvent apprécié pour sa simplicité de flux. Mais l’exécution PHP via FastCGI doit être réglée avec précision. Un mauvais root, un mauvais try_files, ou une mauvaise inclusion de fastcgi_params peuvent ouvrir des chemins.
Un root cohérent et un try_files prudent
Sur WordPress, Nginx s’appuie généralement sur une logique de routage pour servir l’URL proprement. L’erreur fréquente, c’est d’avoir un root qui ne correspond pas à la réalité du disque, puis de compenser avec des règles trop permissives.
En durcissement, l’objectif est de réduire les cas où Nginx “tente” d’interpréter une requête autrement. try_files peut être une arme, ou une brèche selon son expression.
Si, par exemple, un chemin inattendu est mappé vers l’entrée WordPress (souvent index.php) dans des cas où vous ne voulez pas, un attaquant peut explorer des comportements. Cela ne veut pas dire “interdire tout”. Cela veut dire “contrôler la logique”.
Protéger l’accès aux fichiers cachés
WordPress s’appuie sur des fichiers et dossiers présents dans son arborescence. Nginx, contrairement à Apache, n’a pas la même logique implicite de protections via .htaccess, car .htaccess n’est pas lu de la même manière (et n’existe pas dans Nginx tel quel).
Vous devez donc veiller à:
- bloquer l’accès à des fichiers cachés, contrôler les permissions, et s’assurer que les fichiers de configuration et de déploiement ne sont pas servis.
En pratique, un durcissement courant consiste à empêcher l’accès direct aux “dotfiles”, tout en gardant l’exception nécessaire pour certains assets ou mécanismes (selon votre stack). C’est un point où des sites “marketing” et des sites “full stack” ne réagissent pas pareil.
Verrouiller la passerelle FastCGI et les paramètres
FastCGI doit transmettre correctement les variables d’environnement attendues par PHP, et seulement celles-là. Une fuite de variables internes, ou des paramètres incohérents, peuvent aider un attaquant à comprendre le serveur.
L’autre aspect, c’est la gestion des chemins. Si Nginx laisse passer des chemins qui finissent quand même en exécution, vous perdez l’avantage du contrôle. C’est pourquoi la cohérence entre server_name, root, location, et l’exécution PHP est essentielle.
Détails qui comptent vraiment: permissions et ownership
Même avec une configuration serveur parfaite, des permissions trop larges peuvent ruiner la sécurité. WordPress doit écrire dans certaines zones (uploads, éventuellement cache), pas partout.
Sur les serveurs Linux, je recommande de penser en termes de séparation:
- le serveur web lit, WordPress écrit dans des dossiers précis, l’administrateur (vous) gère les déploiements.
Dans beaucoup d’installations, l’erreur vient d’un “chmod 777” fait pour résoudre un problème rapidement. Une fois en place, ces droits deviennent https://gardewp.fr/securite-wordpress/ un cadeau pour n’importe quel code compromis, même partiel. Et si un attaquant parvient à écrire un fichier dans wp-content, la différence entre “écrire” et “écrire et exécuter” peut devenir critique.
Le bon compromis dépend de votre modèle de déploiement. Si vous utilisez CI/CD et que votre déploiement remplace les fichiers applicatifs, vous pouvez rendre les dossiers applicatifs plus stricts, tout en gardant les uploads accessibles.
TLS et en-têtes: durcir sans casser
Le durcissement ne se limite pas à l’exécution PHP. Les en-têtes et la configuration HTTPS réduisent aussi les risques. Un serveur bien configuré:
- force HTTPS, gère correctement les redirections, et applique des en-têtes de sécurité cohérents.
Sur le terrain, le piège est de copier-coller des en-têtes “typiques” sans vérifier l’impact sur votre site. Certaines règles peuvent casser des intégrations, des formulaires, ou des ressources tierces si vous déclarez des politiques trop strictes.
Une approche pragmatique consiste à partir de ce qui est compatible avec WordPress standard, puis à durcir progressivement si votre stack le supporte.
Séparer ce qui est public de ce qui ne l’est pas
WordPress, par défaut, expose un ensemble de scripts et d’URL. Cela ne veut pas dire que tout est vulnérable. Mais quand un attaquant explore, il aime cartographier.
Sur Apache ou Nginx, vous pouvez améliorer la “navigabilité pour l’attaquant” en contrôlant:
- ce que vous servez en erreur, les index de répertoires, l’accès à des chemins inutiles.
Je préfère une stratégie simple: si un dossier n’a aucune raison d’être listé, interdisez le listing. Si certains fichiers ne doivent jamais être servis, bloquez-les explicitement. Cela réduit les indices disponibles.
Réécrire proprement, sans donner d’options étranges
Les règles de réécriture URL sont normales pour WordPress, mais elles sont aussi un terrain d’abus. Un rewrite trop permissif peut envoyer un grand nombre de requêtes vers le même point, souvent index.php, et rendre plus difficile la détection de comportements anormaux.
Le bon niveau de contrôle dépend de votre politique de sécurité et de vos logs. Si vous avez un WAF, un pare-feu applicatif ou au moins un reverse proxy qui filtre, vous pouvez tolérer plus de souplesse côté rewriting, à condition que les logs soient exploitables.
En l’absence de couche externe, mieux vaut un serveur qui “refuse” plus de choses. Vous ne voulez pas que le serveur soit un aspirateur à requêtes ambiguës.
Limiter le débit et réduire l’impact des attaques
Les attaques par force brute, les tentatives répétées, ou les requêtes “polluantes” ne passent pas uniquement par la couche WordPress. Le serveur peut déjà réduire l’impact.
Le durcissement ici doit rester cohérent avec vos utilisateurs légitimes. Un site peu fréquent peut supporter une politique stricte. Un site très exposé, ou un site avec des acteurs sensibles à la latence, demande plus de finesse.
Sans entrer dans des réglages trop spécifiques à chaque distribution et sans inventer de valeurs, retenez l’idée suivante: vous cherchez à limiter les rafales (bursts) et à ralentir quand des motifs anormaux s’accumulent. C’est souvent plus utile que des blocages absolus.
Logs: votre meilleure boussole pendant le durcissement
Après une modification de configuration, les logs vous disent si vous avez durci correctement ou si vous avez introduit un comportement inattendu.
- Sur Apache, vérifiez les logs d’erreur et l’accès. Sur Nginx, observez les logs error et access, surtout autour des codes 403, 404 et 500. Sur PHP, vérifiez les logs PHP-FPM si vous utilisez un pool.
Une amélioration pragmatique: mettez en place une routine de test rapide après chaque changement. Un “petit” durcissement peut avoir un effet secondaire, par exemple sur un endpoint de téléchargement, un fichier de thème, ou un mécanisme de cache.
Trade-offs réels: quand trop verrouiller devient un problème
Renforcer sécurité WordPress, ce n’est pas juste ajouter des règles. C’est aussi accepter que certaines règles “plus strictes” demandent une maintenance.
Quelques exemples typiques:
- Bloquer les dotfiles peut casser certains fichiers de configuration ou des endpoints attendus par un outil, selon la stack. Interdire trop d’extensions peut casser un plugin qui sert des fichiers non standards. Des politiques de sécurité d’en-têtes trop agressives peuvent casser des scripts ou des formulaires. Une limitation de débit mal calibrée peut pénaliser des clients légitimes (API, bots internes, services de monitoring).
La solution n’est pas de ne rien faire. La solution est d’implémenter par petites étapes, et d’utiliser les logs comme preuve.
Une checklist de durcissement serveur (Apache/Nginx)
Je limite volontairement à des actions générales, valables sur la plupart des environnements WordPress. Adaptez-les à votre hébergement et à votre architecture.
- Vérifier que l’arborescence publique ne contient pas de fichiers sensibles accessibles via le web (configuration, backups, logs). S’assurer que l’exécution PHP est limitée aux emplacements attendus (pas d’exécution via des chemins détournés). Bloquer l’accès aux fichiers cachés non nécessaires, tout en conservant les exceptions légitimes à votre stack. Mettre en place une gestion d’erreur “sobre” côté public, et détaillée dans les logs. Contrôler le listing de répertoires et supprimer la possibilité de navigation par défaut vers des dossiers.
Deux exemples de cas où j’ai vu des configurations se tromper
Cas 1: “C’est WordPress, il gère tout”
Sur un site où les mises à jour WordPress étaient régulières, l’équipe pensait que “le reste suivrait”. Pourtant, le serveur servait des fichiers cachés non prévus, et un répertoire de travail restait accessible. À partir de là, un attaquant a pu récupérer des indices, ce qui a accéléré la phase d’exploration. WordPress n’était pas compromis tout de suite, mais l’attaquant avait gagné du temps.
Le durcissement côté serveur a réglé le problème à la racine, pas “par patch”. C’est une leçon: la suppression des informations gratuites est un investissement direct.
Cas 2: “On a durci, puis tout a ralenti”
Sur un autre déploiement, des règles de limitation et des politiques de requêtes ont été ajoutées pour se protéger. Le site fonctionnait, mais certains clients, notamment derrière des proxys, recevaient davantage d’erreurs et des latences. La configuration était trop rigide sur des détails qui semblaient anodins: headers et tolérance de requêtes atypiques.
La correction n’a pas consisté à enlever la sécurité. Elle a consisté à ajuster les règles pour distinguer les cas légitimes des cas ambigus, puis à affiner à partir des logs et des retours.
Vérifications finales: tester sans se faire piéger
Après durcissement, testez au moins ces dimensions:
- navigation normale (pages, thèmes, formulaires), chargement des assets (CSS, JS, images), uploads (media library), accès à des pages d’erreur (404) pour vérifier la sobriété, comportements d’un plugin connu si vous en utilisez (SEO, caching, sécurité).
Si vous utilisez un cache serveur ou un CDN, testez aussi derrière, parce que la logique de redirection et les en-têtes peuvent se superposer. Un serveur peut être “durci” correctement et un CDN peut ajouter une couche de transformation. Résultat: ce que vous observez localement n’est pas toujours identique en production.
Choisir la bonne profondeur: Apache ou Nginx ne change pas le fond
Apache et Nginx ont des styles différents, mais la philosophie est la même. Vous réduisez la surface d’attaque en:
- contrôlant l’exécution, limitant l’exposition de fichiers, rendant les erreurs plus discrètes, et améliorant le filtrage des requêtes.
Au final, la meilleure configuration est celle qui correspond à votre manière d’opérer. Un serveur “trop universel” finit souvent par être “trop large”. Un serveur “trop spécifique” finit par être fragile lors des mises à jour ou des changements de stack.
Le bon durcissement est un compromis conscient, appuyé sur des logs et des tests, pas sur des recettes figées.
Quoi faire maintenant, concrètement
Si vous voulez avancer sans tout casser, mon conseil est de commencer par les changements à impact faible et bénéfice élevé, puis de progresser.
- Revoyez d’abord ce qui est servi par défaut (fichiers cachés, listing, erreurs). Ensuite, vérifiez l’exécution PHP et la cohérence des chemins. Enfin, ajoutez des protections plus “opérationnelles” comme le contrôle de débit, les en-têtes et les politiques de requêtes, toujours en vous appuyant sur vos logs.
Si vous me donnez votre configuration actuelle (Apache ou Nginx, PHP-FPM ou mod_php, présence de CDN ou reverse proxy, OS et distribution, et ce que vous utilisez exactement pour WordPress), je peux vous proposer un plan de durcissement plus ciblé, avec des points de contrôle pour éviter les erreurs classiques.