Apache2 reste l’un des serveurs web les plus utilisés pour héberger WordPress. Bien configuré, il est robuste et flexible. Mais dans sa configuration par défaut, il expose souvent trop d’informations, accepte des comportements inutiles et n’envoie pas les headers de sécurité modernes (CSP, HSTS, etc.).
Dans ce guide, vous allez voir comment durcir Apache2 pour WordPress en 2025 : configuration SSL propre, options de répertoires, headers de sécurité, mise en place d’une Content Security Policy (CSP) adaptée à WordPress et gestion de RemoteIP quand le serveur est derrière Cloudflare ou un autre reverse proxy.
Résumé rapide : Pour sécuriser Apache2 avec WordPress : passez tout en
HTTPS (SSL propre), désactivez directory listing, limitez AllowOverride, masquez la version
d’Apache/PHP, ajoutez les headers de sécurité (HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy) et
mettez en place une CSP progressive. Si vous êtes derrière Cloudflare, configurez mod_remoteip pour
voir les vraies IP.
Sommaire
1. Pourquoi durcir Apache2 pour WordPress ?
WordPress lui-même doit être sécurisé (mises à jour, plugins, mots de passe forts, WP Cerber, etc.), mais il repose sur un socle : le serveur web. Si Apache2 est mal configuré, vous pouvez vous retrouver avec :
- des répertoires listés librement (directory listing),
- des fichiers sensibles accessibles,
- des headers qui révèlent la version exacte d’Apache/PHP,
- aucun header de sécurité moderne,
- et, derrière Cloudflare, des logs qui montrent uniquement les IP de Cloudflare.
L’objectif du hardening est donc :
- de réduire la surface d’attaque,
- de protéger les utilisateurs (XSS, clickjacking, etc.),
- de préparer le terrain pour les plugins de sécurité WordPress.
2. VirtualHost et HTTPS : base saine avant le hardening
Avant d’ajouter des headers avancés, assurez-vous que vos VirtualHosts sont propres et que tout passe en HTTPS.
2.1. Un VirtualHost par site
Sur un serveur multi-sites, créez un VirtualHost distinct par domaine, avec son
ServerName et, si besoin, ses ServerAlias. Cela facilite la gestion des
certificats, des logs et des options propres à chaque site.
2.2. Forcer le HTTPS
Selon votre setup (Cloudflare ou non), vous pouvez :
- configurer une redirection HTTP → HTTPS dans Apache,
- ou utiliser les règles de redirection côté Cloudflare (Page Rules / Redirects).
Le but est que toutes les URL publiques de votre site utilisent HTTPS, ce qui permet ensuite d’activer HSTS et d’éviter le mixed-content.
3. Options de répertoires : index, symlinks, .htaccess
La section <Directory> d’Apache2 est souvent sous-estimée. C’est pourtant là que vous
contrôlez des aspects critiques.
3.1. Désactiver le directory listing
Évitez de laisser lister le contenu des répertoires :
Options -Indexes +FollowSymLinks
Avec WordPress, vous n’avez pas besoin de voir les fichiers d’un répertoire dans le navigateur. C’est inutile et peut aider un attaquant à cartographier votre site.
3.2. Limiter l’usage de .htaccess
Sur un serveur que vous contrôlez entièrement, il est plus propre de mettre la majorité de la configuration
dans les fichiers .conf d’Apache, et non dans des .htaccess disséminés.
Vous pouvez par exemple limiter :
AllowOverride FileInfo Options
Ou, sur certains environnements maîtrisés, désactiver complètement AllowOverride et gérer les
règles de réécriture dans le VirtualHost. Dans un contexte WordPress “classique”, on reste souvent sur un
compromis : AllowOverride All sur DocumentRoot, mais pas sur d’autres chemins
sensibles.
3.3. Protéger certains répertoires
Côté WordPress, on protège en général :
- les fichiers de configuration (ex.
wp-config.php), - les dossiers qui ne doivent pas servir de script (ex. certains sous-dossiers de
wp-content), - les répertoires de logs ou de backup si vous en avez dans
DocumentRoot(à éviter).
4. Headers de sécurité indispensables
Les headers HTTP sont un premier rempart contre certaines classes d’attaques, et améliorent la protection du navigateur.
4.1. Masquer la version d’Apache/PHP
Dans apache2.conf ou un fichier global :
ServerSignature Off
ServerTokens Prod
Côté PHP (fichier php.ini) :
expose_php = Off
L’idée est d’éviter de donner gratuitement la version exacte de vos logiciels à un attaquant.
4.2. Headers à ajouter
Dans votre VirtualHost ou un fichier inclus :
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-XSS-Protection "0"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=(), fullscreen=(self)"
Pour HSTS (uniquement si tout votre site est correctement en HTTPS) :
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Attention : HSTS est difficile à “retirer” une fois pris en compte par les navigateurs. Activez-le seulement si vous êtes sûr de votre configuration HTTPS.
5. Content Security Policy (CSP) adaptée à WordPress
La Content Security Policy permet de définir précisément quelles sources sont autorisées pour les scripts, les styles, les images, etc. C’est un outil puissant contre les attaques XSS, mais il peut aussi casser votre site si elle est trop restrictive.
5.1. Approche progressive
Ne commencez pas par une CSP ultra-stricte. Mieux vaut démarrer en mode “report-only” :
Header set Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline' https:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:;"
Puis :
- analysez les rapports (ou la console navigateur),
- ajustez les directives,
- passez progressivement en
Content-Security-Policy“classique”.
5.2. Particularités WordPress
WordPress et certains plugins :
- injectent du inline JS/CSS,
- chargent des assets depuis des CDNs (Google Fonts, JS externes, etc.),
- utilisent parfois
eval()ou des constructions dynamiques.
C’est pour cela qu’on commence souvent avec 'unsafe-inline' et des domaines https:
autorisés, puis on resserre au fur et à mesure en retirant les exceptions au profit de scripts balisés
(nonce, hash) lorsque c’est possible.
6. Derrière Cloudflare : RemoteIP et logs
Si votre serveur est derrière Cloudflare, toutes les requêtes arrivent d’adresses IP Cloudflare. Sans configuration spécifique, Apache voit toujours Cloudflare comme client et non l’IP réelle du visiteur. Cela complique :
- les logs d’accès,
- les systèmes de sécurité (fail2ban, WP Cerber, CrowdSec),
- la détection d’attaques.
6.1. Activer mod_remoteip
Chargez le module remoteip puis, dans votre configuration :
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1
Et ajoutez les plages IP Cloudflare comme proxies de confiance (liste officielle). Apache réécrira alors l’IP client dans ses logs, ce qui permettra à vos outils de sécurité de fonctionner correctement.
6.2. Formats de logs adaptés
Assurez-vous que votre LogFormat utilise %a (adresse client apparente) et non
%h, pour tenir compte de mod_remoteip. Par exemple :
LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
7. Tester et déployer les changements en production
Un hardening Apache2 doit être déployé progressivement :
- Testez d’abord sur un environnement de préproduction ou un sous-domaine de test.
- Surveillez les logs d’erreur Apache et la console navigateur (CSP, mixed content, etc.).
- Validez les fonctionnalités critiques : login WordPress, back-office, formulaires, paiement si e-commerce.
Ensuite seulement, appliquez globalement les changements sur vos VirtualHosts de production, site par site.
Pour aller plus loin, vous pouvez compléter ce durcissement Apache2 avec :
- un plugin de sécurité WordPress (par exemple WP Cerber),
- Cloudflare (WAF + CDN),
- CrowdSec ou fail2ban côté serveur.
FAQ – Apache2 & sécurité WordPress
Faut-il tout gérer dans .htaccess ou dans les fichiers .conf d’Apache ?
Sur un serveur que vous administrez vous-même, il est préférable de mettre la configuration principale
(headers, règles globales) dans les fichiers .conf. Les .htaccess restent utiles
pour les réécritures gérées par WordPress, mais moins ils contiennent de logique critique, mieux c’est.
Une CSP trop stricte peut-elle casser mon site ?
Oui. C’est pour cela qu’il faut commencer en mode Report-Only, vérifier les rapports et les erreurs dans la console, puis durcir progressivement. Certains builders ou plugins injectent du inline JS/CSS qui doit être pris en compte.
Est-ce que Cloudflare remplace le hardening Apache2 ?
Non. Cloudflare protège et optimise la couche réseau en amont, mais vous devez quand même sécuriser votre serveur web (Apache2), votre PHP, votre base de données et votre WordPress lui-même. Les deux couches sont complémentaires.
Les headers de sécurité suffisent-ils à sécuriser un site WordPress ?
Non, ils ne sont qu’une partie du dispositif. Ils aident surtout à protéger le navigateur et à réduire l’impact de certaines vulnérabilités. Vous devez aussi gérer les mises à jour, les droits fichiers, l’authentification forte, la limitation des tentatives de login, etc.
Est-ce risqué d’activer HSTS ?
HSTS renforce la sécurité, mais si vous l’activez alors que votre site n’est pas 100 % en HTTPS ou si vous devez repasser en HTTP pour une raison technique, vous pouvez vous enfermer dans une situation compliquée. Assurez-vous que tout est bien en HTTPS avant de l’activer avec une durée longue.
Conclusion : Apache2 comme première ligne de défense
Durcir Apache2 pour WordPress, c’est transformer un serveur “par défaut” en un composant sécurisé de votre infrastructure. En verrouillant les options de répertoires, en ajoutant les headers de sécurité, en mettant en place une CSP progressive et en configurant correctement RemoteIP derrière Cloudflare, vous réduisez considérablement la surface d’attaque et améliorez la protection quotidienne de vos sites.
Combiné à une architecture serveur bien pensée, à un PHP-FPM tuné, à une base MySQL/MariaDB optimisée et à un cache robuste (Redis, Cloudflare), ce hardening Apache2 devient une brique essentielle de votre plateforme WordPress professionnelle.
