Quand on parle de sécurisation WordPress, on pense souvent aux plugins, à l’authentification et aux mises à jour. Tout cela compte, bien sûr. Mais dans la vraie vie, une grande partie des risques se joue avant même que WordPress ne soit sollicité, au niveau de votre serveur Apache: gestion des répertoires, droits, contrôle des chemins, limitation des méthodes HTTP, entêtes, exposition des erreurs, et comportement en cas de requête étrange.
Je l’ai vu sur des installations pourtant “à jour”. Le code WordPress était sain, les plugins aussi, mais Apache laissait traîner des indices: URLs internes renvoyant des pages d’erreur bavardes, répertoires servis par liste, traces de fichiers de sauvegarde accessibles, ou règles trop permissives sur certaines routes. Résultat, pas forcément une compromission immédiate, mais une surface d’attaque inutilement large.
L’objectif ici est de passer Apache en configuration “ferme”, sans casser votre site. On va raisonner sur des choix pratiques, avec des variantes selon vos habitudes (mod_php, PHP-FPM, virtualhost, multi-sites).
Pourquoi Apache mérite votre attention
Apache se comporte comme un gardien à l’entrée. Il décide quoi faire quand quelqu’un demande une ressource. Si ce gardien réagit mal à des cas limites, un attaquant peut explorer, amplifier ou contourner des protections plus haut dans la pile.
Quelques exemples typiques rencontrés:
- Un serveur qui liste le contenu d’un dossier (option Indexes) finit par exposer des uploads, des dumps temporaires, voire des fichiers laissés par accident. Des fichiers sensibles deviennent accessibles parce qu’ils “existent” quelque part dans l’arborescence, par exemple des fichiers .env, .htaccess de travail, backups, ou archives de déploiement. Les erreurs HTTP retournent trop de détails, ce qui accélère l’identification des versions, des modules et du cheminement interne. La méthode HTTP TRACE ou certaines méthodes non utilisées sont autorisées, et ça peut ouvrir des scénarios de contournement.
Ce n’est pas qu’Apache “fait tout” en sécurité, c’est qu’il peut soit réduire la curiosité externe, soit l’alimenter.
Faire le point: ce que vous devez connaître avant de modifier
Avant d’éditer des directives, prenez deux minutes pour vérifier votre architecture. Sur WordPress, le plus important est de savoir comment PHP est exécuté et quel rôle jouent vos .htaccess.
Deux questions rapides:
- Est-ce que vous utilisez mod_php directement, ou PHP-FPM derrière un proxy (souvent via proxy_fcgi avec Nginx, mais Apache peut aussi faire du FPM)? Est-ce que WordPress s’appuie sur des réécritures via .htaccess dans le dossier racine, ou tout est géré côté VirtualHost?
Dans un scénario classique, WordPress a besoin d’mod_rewrite et d’un .htaccess pour les permaliens. Vous pouvez durcir Apache, mais il faut éviter de casser cette chaîne.
Si votre site est dans un VirtualHost, c’est souvent plus propre de mettre la majorité des règles au niveau VirtualHost, plutôt que dans .htaccess. Les deux approches fonctionnent, mais le VirtualHost est en général plus prévisible, moins fragile, et plus simple à auditer.
VirtualHost: une base plus propre que des bricolages dans .htaccess
Si vous avez la main sur la configuration du site dans /etc/apache2/sites-available/... (Debian/Ubuntu) ou dans votre équivalent (ou panel de hosting), partez d’un VirtualHost solide. Le .htaccess peut rester minimal, chargé surtout des règles de WordPress.
L’idée n’est pas de tout bloquer à l’excès, mais de mettre trois couches:
Un socle réseau et protocole (limiter ce qui ne sert pas). Des règles d’accès au système de fichiers (éviter l’exposition). Des règles de réponse (éviter les révélations via erreurs et headers).Au passage, pensez aux droits Unix du dossier WordPress. Si Apache n’a pas besoin d’écrire, il ne doit pas pouvoir le faire. Les protections “Apache” ne compensent pas un dossier trop permissif côté fichiers.
Contrôler les méthodes HTTP et réduire l’empreinte
WordPress n’a pas besoin de toutes les méthodes HTTP, surtout en front. Selon votre configuration, certaines méthodes comme GET, POST et parfois HEAD sont légitimes. TRACE n’a pas d’usage utile dans ce contexte.
Dans le VirtualHost, vous pouvez ajouter des règles pour bloquer les méthodes non nécessaires. En pratique, je recommande surtout de désactiver TRACE (et éventuellement TRACK). Selon vos modules, vous pouvez le faire via TraceEnable Off au niveau global, ou via des restrictions de configuration locale.
Attention toutefois: certains outils de monitoring ou de sécurité peuvent utiliser des méthodes spécifiques. Le bon réflexe est de tester après modification, d’abord sur un environnement de préproduction ou au moins pendant une fenêtre courte, en observant les logs d’accès.
Verrouiller l’accès aux répertoires et éviter les fuites
Le classique: interdire la navigation des répertoires. Sur WordPress, vous ne voulez pas que quelqu’un puisse ouvrir https://domaine.tld/wp-content/ ou https://domaine.tld/ et obtenir une liste.
Côté Apache, vérifiez que Options Indexes n’est pas activé pour la racine et les dossiers WordPress. Et si votre configuration hérite de valeurs globales, c’est parfois un piège: Options au niveau global peuvent “remonter” sauf contre-mesures.
Pour éviter les surprises, une stratégie robuste consiste à définir, au niveau du DocumentRoot du site WordPress, des options explicitement adaptées, du type: pas de listing de répertoires, pas d’exécution directe de scripts hors de l’usage prévu, pas d’options inutiles comme FollowSymLinks si vous n’en avez pas besoin.
Autre point, très concret: l’exposition des fichiers et répertoires “cachés”. Beaucoup de serveurs laissent des fichiers comme .htaccess, .env, ou des dossiers de travail accessibles si rien ne les bloque. Même si ces fichiers ne sont pas présents en temps normal, un déploiement raté ou un script de sauvegarde peut en laisser.
Bloquer l’accès aux fichiers sensibles (et aux “accidents” courants)
Les attaques opportunistes cherchent souvent des fichiers qui “devraient” être non accessibles. Ce sont rarement des fichiers “exotiques”, ce sont plutôt des noms familiers: sauvegardes, archives, fichiers de configuration, journaux, ou traces.
Sans inventer de liste au hasard, l’approche raisonnable consiste à bloquer ce qui est connu pour être sensible dans un environnement WordPress et applicatif.
Typiquement, on cible:
- les fichiers qui commencent par un point dans le DocumentRoot (ex: .htaccess, .env, .git, .htpasswd), avec prudence car .htaccess est nécessaire à WordPress. Donc on ne bloque pas tout aveuglément, on bloque ce qui est utile à interdire sans casser le fonctionnement. les extensions de sauvegarde, par exemple .bak, .old, .zip de déploiement, .tar.gz d’export. les fichiers de type “env” et “ini” si jamais ils sont déposés par un script.
Une règle bien faite évite de casser un usage légitime. Par exemple, bloquer tous les fichiers “.txt” peut gêner la livraison de certains fichiers statiques. Bloquer wp-config.php est une évidence, mais WordPress et vos outils ne devraient jamais le servir publiquement.
Si vous utilisez un dossier de staging accessible, attention aussi à sa configuration. Les protections Apache doivent couvrir le staging de la même manière, sinon vous créez un “port” oublié.
Désactiver l’exécution de scripts dans les dossiers non pertinents
Un WordPress moderne tourne essentiellement via index.php et des fichiers PHP dans le cœur et certains plugins. Cela ne veut pas dire que des fichiers PHP ailleurs doivent pouvoir s’exécuter.
Selon votre configuration, vous pouvez restreindre l’exécution PHP à l’endroit prévu, ou au minimum empêcher l’exécution dans certains sous-dossiers qui ne devraient pas héberger du PHP (uploads, caches, templates compilés si vous n’en utilisez pas).
Le piège classique est de casser un plugin qui écrit un fichier et l’exécute, ou un mécanisme d’images dynamiques. Dans ce genre de cas, vous devez trancher avec des règles plus ciblées, en vous appuyant sur les dossiers réels de votre installation.
C’est là que l’expérience compte: avant de durcir “tout”, inspectez ce que WordPress et vos plugins font réellement. Regardez wp-content/uploads, les caches, et les dossiers spécifiques des plugins. Un durcissement aveugle sur des répertoires “upload” suffit souvent, mais pas toujours.
Configuration d’erreurs: moins de détails, plus de sécurité
Un point que les hébergeurs oublient parfois: les pages d’erreur renvoient des informations trop verbeuses. Sur une installation WordPress, les erreurs 403, 404 et 500 peuvent révéler des détails utiles à une enquête.
L’idée n’est pas de masquer la réalité au point de perdre en diagnostic, c’est de contrôler ce que l’utilisateur externe voit. En général:
- côté production, vous voulez des messages courts. les détails techniques doivent aller dans les logs serveur, pas dans la réponse HTTP.
Sur Apache, vous pouvez configurer des pages d’erreur personnalisées pour certains codes, ou au moins éviter les réponses par défaut trop bavardes. De plus, travaillez le contenu des logs: surveillez error.log et access.log avec des filtres. Quand quelque chose casse, vous devez retrouver le diagnostic sans exposer au public.
J’ai déjà vu une configuration où les 404 renvoyaient le chemin complet du fichier recherché. C’est pratique au début, puis ça devient une fuite d’information gratuite.
Désactiver la symlink et limiter la traversée
Les liens symboliques peuvent être une surface de confusion. Si vous n’en avez pas l’usage, limitez leur suivi. Les options Apache comme FollowSymLinks doivent être activées uniquement si nécessaire.
Sur une installation WordPress, certains préfèrent utiliser des symlinks pour partager des dossiers entre environnements. Si c’est votre cas, vous pouvez ajuster la portée de FollowSymLinks à ces emplacements précis, plutôt que de le laisser global.
En parallèle, si vous utilisez des répertoires montés ou des volumes partagés, vérifiez que la configuration respecte votre intention. Un mauvais montage peut conduire à ce que des fichiers inattendus deviennent accessibles via le chemin DocumentRoot.
Sécuriser l’usage de .htaccess sans lui laisser le volant
Beaucoup de WordPress utilisent .htaccess. Mais .htaccess peut aussi devenir un “moteur de surprises” quand la configuration est trop permissive.
Deux axes:
- limiter ce que .htaccess peut faire, en activant seulement les directives nécessaires dans la racine. contrôler quelles directives sont autorisées via AllowOverride.
Si AllowOverride All est en place dans la racine, c’est plus compliqué à maîtriser. Vous voulez une liste restreinte, typiquement pour FileInfo et Options, selon vos headers sécurité WordPress besoins. Les détails dépendent de votre cas, notamment du fonctionnement de WordPress et des permaliens.
Trade-off réel: plus vous restreignez AllowOverride, plus vous réduisez la flexibilité. Dans certains environnements gérés par un hébergeur, vous n’aurez pas le choix. Dans les environnements maîtrisés, c’est souvent un bon levier.
Headers de sécurité: utile, mais à manier avec prudence
Les headers ne remplacent pas la sécurisation de la logique applicative, mais ils réduisent certaines classes d’attaques et surtout, ils clarifient le comportement côté navigateur.
Pour Apache, vous pouvez ajouter des en-têtes comme:
- Content-Security-Policy (CSP) pour limiter ce que la page peut charger. X-Content-Type-Options (souvent via nosniff). Referrer-Policy plus restrictive. X-Frame-Options ou l’équivalent moderne via directive CSP frame-ancestors.
Le point clé: CSP peut casser un site si vous ne l’avez pas calibrée. WordPress, selon les thèmes et les plugins, injecte scripts, styles et ressources de multiples origines (Google Fonts, analytics, reCAPTCHA, CDN, polices). Si vous activez CSP trop strict tout de suite, vous allez obtenir une pluie d’éléments cassés.
Dans une démarche de sécurisation Apache, je recommande souvent de commencer par les headers simples qui causent peu de casse, puis de passer à CSP après audit.
Un exemple de règles Apache à adapter (sans copier-coller aveugle)
Je vous donne un exemple de logique de configuration, pas une recette unique. Les directives exactes dépendent de votre structure et de vos modules.
L’idée, dans votre VirtualHost, est de:
- interdire les répertoires indexés, bloquer l’accès à des fichiers sensibles, limiter l’exécution selon vos besoins, personnaliser les erreurs et éviter d’exposer des détails, s’assurer que les réécritures de WordPress fonctionnent.
Voici une structure de réflexion (en prose), car le copier-coller brut peut créer des conflits avec vos règles existantes. Par exemple, si votre .htaccess WordPress gère déjà des exceptions, vous ne voulez pas le dupliquer dans tous les sens au niveau VirtualHost.
Si vous souhaitez, je peux aussi vous aider à rédiger une version précise à partir de votre VirtualHost actuel, à condition que vous partagiez les éléments non sensibles (DocumentRoot, nom de domaine, présence de .htaccess, et si vous utilisez mod_php ou proxy vers PHP-FPM).
Requêtes suspectes et logs: la partie “sécurité” que personne ne voit
Un durcissement n’est utile que s’il est observé. Après changement d’Apache, je recommande de surveiller au minimum:
- les erreurs 403 et 404, avec les chemins demandés. Un pico de 404 peut être normal, mais des patterns nouveaux sont un indice. les erreurs 500. Si vous voyez une hausse, vous avez probablement cassé une règle ou un chemin. les pics d’accès sur des fichiers “bizarres” (tentatives d’accès aux backups, fichiers cachés, ou paths d’install).
Dans mes interventions, une règle bloquante mal ciblée se trahit par une hausse immédiate de 404 sur des ressources réellement utilisées. Dans ce cas, on ajuste. L’important est de tester, comparer avant et après.
Au passage, pensez à la corrélation avec WordPress. Si vous bloquez un fichier d’index ou une route d’upload, WordPress peut renvoyer des comportements inattendus, mais la cause se lit souvent dans les logs Apache.
Un checklist pragmatique (maximum d’impact, minimum de casse)
Voici un premier tour de table, adapté à la sécurisation WordPress côté Apache. À faire dans un environnement de test si possible.
Désactiver le listage de répertoires, vérifier que Indexes n’est pas actif pour le DocumentRoot. Bloquer l’accès aux fichiers sensibles et aux extensions de sauvegarde ou d’archives déposées par accident. Contrôler AllowOverride et valider que WordPress fonctionne toujours avec vos permaliens. Réduire les détails d’erreurs côté client, garder la verbosité dans les logs serveur. Vérifier les méthodes HTTP réellement nécessaires, désactiver TRACE si encore autorisé.Cette liste est volontairement courte, parce que dans un projet réel, les erreurs arrivent moins via “oubli complet” et plus via réglage trop ambitieux au mauvais endroit.
Edge cases qui reviennent souvent
La sécurité n’est pas qu’une question de règles, c’est aussi une question d’exception.
Les plugins de cache et les dossiers temporaires
Certains plugins génèrent des fichiers temporaires ou utilisent des caches dans wp-content/cache ou ailleurs. Si vous bloquez l’exécution PHP ou l’accès à certains dossiers, vérifiez ce que le plugin écrit. Le plus souvent, ces dossiers contiennent des fichiers statiques, donc votre durcissement tient, mais pas toujours.
Les sites avec import/export
Les plugins d’import peuvent parfois déposer des fichiers temporaires, ou des caches d’images. Si vous bloquez trop d’extensions, vous pouvez casser ces flux. Le diagnostic se fait dans les logs, et sur les étapes de workflow. Un test d’import après durcissement vaut de l’or.
Les scripts de déploiement
Les pipelines CI/CD déposent parfois des archives et les suppriment ensuite. Une règle “bloque tout ce qui ressemble à une archive” est souvent bonne, mais vérifiez que le fichier n’est pas servi pendant la fenêtre de déploiement. Même une courte exposition compte quand quelqu’un scanne en continu.
Les hébergements mutualisés
Sur un hosting partagé, vous n’avez pas toujours le contrôle du VirtualHost. Il faut alors raisonner via .htaccess. Mais le principe reste: limiter Options dangereuses, bloquer les fichiers sensibles, et garder WordPress fonctionnel. Les droits imposés par l’hébergeur peuvent aussi influencer la manière d’appliquer les restrictions.
Tester sans se tirer une balle dans le pied
Avant de mettre en production, testez de façon méthodique.
- Testez les pages normales: accueil, articles, catégories, recherche interne. Testez les permaliens et les redirections, surtout si vous avez ajouté ou modifié mod_rewrite. Testez l’accès aux médias: une règle mal calibrée sur uploads est vite visible. Testez un 404 volontaire, par exemple une URL factice. Vous voulez un comportement cohérent (et pas de fuite de chemin).
Si vous avez accès à un outil d’analyse de logs, comparez le volume de 403 et 404 avant et après. Le bon durcissement doit augmenter les rejets sur des paths suspects, pas bloquer des ressources légitimes.
Sécuriser au delà d’Apache, sans perdre le fil
Même si le sujet ici est Apache, je préfère rappeler une réalité opérationnelle: un durcissement serveur ne remplace pas les fondamentaux applicatifs.
Pour une approche cohérente de la sécurisation WordPress, vous aurez aussi besoin de:
- mises à jour régulières de WordPress et des plugins, comptes admin protégés, mots de passe forts, réduction du nombre d’utilisateurs, sauvegardes testées, surveillance et durcissement applicatif (telle que la limitation du login, selon votre contexte), configuration correcte de PHP (désactivation des fonctions dangereuses si c’est possible, limites de taille, etc.).
Le serveur est la première couche, mais l’ensemble doit rester aligné.
Les bonnes décisions à garder en tête
La configuration Apache “parfaite” n’existe pas. Il existe une configuration Apache adaptée à votre site, vos plugins, votre hébergeur et votre mode d’exploitation.
Quand vous doutez, je vous conseille d’appliquer ces principes:
- bloquez ce qui n’a aucune raison d’être servi publiquement, gardez la compatibilité avec WordPress et vos permaliens, privilégiez des règles ciblées plutôt qu’un grand “tout bloquer”, observez les logs et ajustez après test.
C’est souvent moins spectaculaire que “installer un plugin magique”, mais ça finit par réduire la surface d’attaque de façon durable.
Deux questions pour personnaliser vos réglages
Si vous voulez, répondez à ces questions et je pourrai vous proposer une configuration plus précise et cohérente avec votre cas:
Votre WordPress s’appuie-t-il sur .htaccess pour les permaliens, et quelle est la valeur actuelle de AllowOverride dans votre VirtualHost? Exécutez-vous PHP via mod_php ou via un mécanisme type FPM (et avez-vous des caches ou des plugins qui écrivent dans des dossiers spécifiques)?Avec ces éléments, on peut avancer vers une sécurisation WordPress plus solide, au niveau Apache, sans casser votre site au premier trafic.