Sécuriser Apache 2.4 : les réglages qui protègent vraiment

La sécurité d'un serveur web ne se résume pas à installer un certificat et à croiser les doigts. J'ai vu trop de serveurs « sécurisés » qui affichaient fièrement leur version d'Apache, laissaient le listing de répertoire actif, et acceptaient des requêtes sans limite de taille. Ce sont rarement les attaques sophistiquées qui font tomber un site. Ce sont les portes laissées ouvertes, les détails qu'on n'a pas pris le temps de fermer. Et la bonne nouvelle, c'est que la plupart de ces portes se ferment avec quelques directives bien choisies.

Dans cet article, je vais vous montrer les réglages qui protègent vraiment. Pas une liste exhaustive de toutes les options possibles, mais une sélection réfléchie, avec le pourquoi de chaque choix. On parlera des informations que votre serveur divulgue sans le savoir, du durcissement TLS, des en-têtes de sécurité, du contrôle d'accès, des limites de ressources, et des pièges à éviter. En 2026, avec l'ANSSI qui publie des recommandations précises et les scanners qui deviennent de plus en plus pointus, ce sujet n'est plus réservé aux experts. Il concerne tous ceux qui administrent un serveur Apache.

Pourquoi la sécurité d'Apache se joue sur des détails

Un serveur Apache par défaut n'est pas fait pour être exposé à Internet. Il est conçu pour fonctionner, pas pour résister. Les valeurs par défaut privilégient la compatibilité et la simplicité. C'est à vous d'ajouter la couche de sécurité, en fonction de votre contexte. Cette couche passe par des détails qui, mis bout à bout, font une vraie différence.

Les erreurs de configuration qui coûtent cher

Les incidents de sécurité que je vois le plus souvent ne viennent pas d'une faille zero-day. Ils viennent d'une configuration laissée par défaut. Un répertoire /admin accessible sans authentification. Un fichier .env listé dans le navigateur. Une version d'Apache affichée en clair, qui oriente un attaquant vers une CVE connue. Un formulaire sans limite de taille qui permettrait un déni de service. Ces erreurs sont silencieuses, mais elles sont exploitables. Et c'est justement ce qui les rend dangereuses : le site continue de fonctionner, l'équipe ne s'aperçoit de rien, et les problèmes s'accumulent.

Une base saine plutôt qu'une liste de correctifs

Il existe des checklists de sécurité, souvent très longues, qui proposent des dizaines de directives à appliquer. C'est utile, mais ce n'est pas suffisant. Une base saine repose sur une compréhension : que dévoile mon serveur, quelles ressources expose-t-il, quelles requêtes accepte-t-il, et quelles traces laisse-t-il. Une fois ces questions posées, les directives arrivent naturellement. C'est l'approche que je privilégie, et c'est celle que je vais développer ici.

Masquer les informations superflues

Un serveur qui parle trop est un serveur qui se met en danger. Chaque information divulguée aide un attaquant à cibler son attaque. La première étape consiste donc à réduire la surface d'information visible. Ce n'est pas de la paranoïa, c'est de l'hygiène élémentaire.

ServerTokens et ServerSignature : ce que vous dévoilez

Par défaut, Apache renvoie un en-tête Server qui indique sa version, son système d'exploitation et parfois les modules chargés. Cette information facilite la vie d'un attaquant qui cherche une CVE correspondant à votre version. La directive ServerTokens contrôle ce niveau de détail. Les valeurs vont de Full (tout) à Prod (minimum). En pratique, je recommande ServerTokens Prod, qui n'affiche que Apache, sans version. ServerSignature contrôle l'affichage dans les pages d'erreur générées par le serveur. ServerSignature Off le désactive complètement. Ces deux directives sont simples, mais elles font une vraie différence.

Le module mod_info et l'URL de statut

mod_info et mod_status exposent des informations précieuses sur la configuration et l'état du serveur. /server-info liste les modules chargés et la configuration. /server-status affiche les connexions en cours. Si ces URL sont accessibles publiquement, un attaquant obtient une carte précise de votre infrastructure. Il faut les restreindre, avec un Require ip, ou les désactiver complètement si vous n'en avez pas besoin. C'est l'une des premières vérifications à faire lors d'un audit.

Retirer les bannières par défaut

Les pages d'erreur par défaut d'Apache révèlent le nom du serveur, la version, parfois le chemin du fichier. Une page 404 personnalisée est plus professionnelle, et plus sûre. Elle évite de donner des indices sur l'infrastructure. De même, Header unset X-Powered-By retire l'en-tête qui indique la version de PHP. C'est un petit détail, mais chaque indication superflue est un cadeau à un attaquant.

Durcir TLS et SSL

HTTPS est devenu indispensable. Mais HTTPS avec des réglages obsolètes est presque aussi dangereux que du HTTP. Les protocoles anciens, comme TLS 1.0 et 1.1, sont considérés comme cassés. Les suites de chiffrement faibles sont exploitables. Le durcissement de TLS n'est pas une option, c'est une nécessité.

SSLProtocol : abandonner TLS 1.0 et 1.1

La directive SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 désactive les protocoles obsolètes. En 2026, seule TLS 1.2 est vraiment nécessaire, TLS 1.3 étant de plus en plus déployé. Une configuration moderne :

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

Les détails varient selon la version d'OpenSSL et les recommandations en vigueur. L'ANSSI publie un guide TLS à jour, et Mozilla propose un générateur de configuration. Utilisez ces sources plutôt que de copier une configuration trouvée sur un blog. Et testez avec SSL Labs, qui donne une note précise de votre configuration.

SSLCipherSuite et les suites recommandées

Le choix des suites de chiffrement dépend de votre public. Si vous supportez des clients très anciens, vous devrez autoriser des suites plus faibles. Si vous visez la sécurité maximale, vous pouvez restreindre aux suites ECDHE avec AES-GCM. Un bon compromis consiste à activer les suites modernes et à désactiver les suites faibles (RC4, DES, 3DES, export). SSL Labs vous aidera à tester et à ajuster.

HSTS : promettre le HTTPS durablement

La directive HSTS (Strict-Transport-Security) indique aux navigateurs que votre site doit toujours être accédé en HTTPS. Une fois reçue, elle empêche l'accès en HTTP pendant la durée spécifiée. Le réglage typique :

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Attention : une fois activée, HSTS est difficile à retirer pour les clients qui l'ont reçue. Testez d'abord avec un max-age court, comme 300 secondes, avant de passer à un an. Et vérifiez que tous les sous-domaines sont bien en HTTPS avant d'utiliser includeSubDomains. Une erreur à ce niveau bloque durablement une partie de votre infrastructure.

OCSP Stapling : gagner en performance et en confidentialité

OCSP Stapling permet au serveur de fournir lui-même la preuve que le certificat est valide, sans que le navigateur ne contacte l'autorité de certification. C'est plus rapide et plus respectueux de la vie privée. La directive SSLUseStapling on active le mécanisme, avec un cache local. Il faut configurer un fichier de cache et vérifier que le certificat fournit bien une réponse OCSP. Quelques lignes de configuration, un gain réel.

Les en-têtes de sécurité HTTP

Les en-têtes de sécurité sont des instructions que le serveur envoie au navigateur pour restreindre certains comportements. Bien configurés, ils limitent les attaques par injection, par clickjacking ou par fuite d'information. Mal configurés, ils cassent des fonctionnalités légitimes. Il faut les choisir avec discernement.

X-Frame-Options face au clickjacking

Le clickjacking consiste à intégrer un site dans une iframe pour tromper l'utilisateur et lui faire cliquer sur des éléments invisibles. X-Frame-Options: SAMEORIGIN bloque l'intégration depuis un autre domaine, tout en permettant l'intégration interne. Certains sites doivent être intégrables ailleurs, dans ce cas DENY n'est pas adapté. Content-Security-Policy offre depuis quelques années une alternative plus puissante avec frame-ancestors, mais X-Frame-Options reste utile pour les navigateurs anciens.

Content-Security-Policy : la directive la plus puissante et la plus fragile

CSP est l'en-tête le plus puissant pour prévenir les injections de script. Il permet de définir les sources autorisées pour les scripts, les styles, les images, etc. Une politique restrictive peut bloquer la majorité des XSS. Mais une politique trop stricte casse le site, et une politique trop laxiste ne protège rien. Je recommande de commencer par un mode rapport, avec Content-Security-Policy-Report-Only, pour observer les violations sans casser le site. Puis, progressivement, durcir la politique. C'est un chantier, pas une opération ponctuelle.

X-Content-Type-Options et le reniflage MIME

Certains navigateurs tentent de deviner le type d'un fichier, même quand le serveur déclare un type. C'est ce qu'on appelle le reniflage MIME. X-Content-Type-Options: nosniff désactive ce comportement, ce qui empêche un fichier .txt d'être interprété comme du JavaScript. Une directive simple, un effet de bord quasi nul, un gain de sécurité réel. À activer sans hésiter.

Referrer-Policy et Permissions-Policy

Referrer-Policy contrôle les informations transmises dans l'en-tête Referer lorsque l'utilisateur quitte votre site. strict-origin-when-cross-origin est un bon compromis, qui protège l'URL complète tout en fournissant le domaine. Permissions-Policy remplace l'ancien Feature-Policy et contrôle l'accès aux fonctionnalités du navigateur (caméra, micro, géolocalisation). Restreindre ces accès par défaut est une bonne pratique, surtout pour les sites qui n'en ont pas besoin.

Le bon usage de Header always set

La directive Header always set applique un en-tête à toutes les réponses, même les erreurs. Header set ne l'applique qu'aux réponses réussies. Pour les en-têtes de sécurité, always est souvent préférable, car il n'y a aucune raison de les omettre sur une page 404. Attention toutefois : sur une redirection, certains en-têtes ne sont pas transmis par le navigateur, ce qui peut donner des comportements inattendus. Testez le résultat réel, pas seulement la présence dans la configuration.

Contrôler les accès et les permissions

Le contrôle d'accès est le cœur de la sécurité. Il détermine qui peut accéder à quoi. Une erreur ici, et c'est une porte ouverte. La 2.4 simplifie la syntaxe, mais elle exige de la rigueur.

Require, RequireAll, RequireAny : les bases du contrôle d'accès

La directive Require est la base. Require all denied bloque tout, Require all granted autorise tout, Require ip et Require host ciblent des sources précises. Les blocs <RequireAll>, <RequireAny> et <RequireNone> combinent ces règles. Par exemple, pour autoriser uniquement le réseau local et les utilisateurs authentifiés :

<RequireAny>
    Require ip 192.168.1.0/24
    Require valid-user
</RequireAny>

Cette configuration est plus lisible que l'équivalent 2.2. Testez chaque bloc, surtout ceux qui protègent des zones sensibles comme les interfaces d'administration.

Authentification Basic contre authentification par certificat

L'authentification Basic est simple, mais le mot de passe circule en base64, ce qui est équivalent à du clair si la connexion n'est pas chiffrée. En HTTPS, c'est acceptable pour un usage interne. Pour un accès plus sensible, l'authentification par certificat client est plus robuste, avec l'avantage d'être résistante au phishing. Elle demande une infrastructure PKI, ce qui n'est pas anodin. À utiliser selon le niveau de sensibilité des ressources protégées.

DirectoryIndex et la protection des répertoires sensibles

Un DirectoryIndex bien configuré évite l'affichage d'un listing de répertoire. DirectoryIndex index.html index.php définit les fichiers prioritaires. Combiné à Options -Indexes, cela empêche un utilisateur de parcourir les répertoires qui n'ont pas d'index. Ne laissez jamais le listing par défaut sur un répertoire contenant des sauvegardes, des fichiers de configuration ou des documents internes.

Options -Indexes et le listage de fichiers

Le listing de fichiers est utile en développement, dangereux en production. Options -Indexes désactive l'autoindexation. Pour les répertoires qui doivent la conserver, activez-la au cas par cas. Cette séparation est plus sûre qu'une activation globale. Sur un site dynamique, le listing par défaut est souvent une erreur, car il révèle la structure du projet. Un attaquant peut y trouver des chemins d'upload, des fichiers de log, ou des sauvegardes.

Limiter les ressources et les attaques

Un serveur qui accepte n'importe quelle requête peut être submergé. Les limites de ressources protègent contre les attaques lentes, les dénis de service et les requêtes abusives. Ces réglages sont souvent négligés, alors qu'ils sont simples à mettre en place.

LimitRequestFields et LimitRequestBody

LimitRequestFields limite le nombre d'en-têtes par requête. LimitRequestBody limite la taille du corps de la requête, ce qui empêche un envoi massif de données. Pour un site classique, LimitRequestBody 10485760 (10 Mo) est un bon point de départ. Pour un site d'upload, adaptez en fonction du besoin. Sans limite, un utilisateur malveillant peut envoyer des requêtes très lourdes qui consomment de la mémoire.

Timeout, KeepAlive et les attaques lentes

Les attaques Slowloris exploitent des connexions maintenues ouvertes très longtemps, avec un envoi très lent. Timeout 30 limite la durée d'une connexion inactive. KeepAliveTimeout 5 ferme rapidement les connexions inactives. Ces valeurs sont un compromis entre performance (KeepAlive économise des handshakes) et sécurité (un timeout court limite l'exposition). Testez en fonction du comportement réel de vos utilisateurs.

Mod_evasive et mod_qos : utiles ou superflus ?

mod_evasive détecte et bloque les attaques par déni de service simple, comme un trop grand nombre de requêtes par seconde depuis une même IP. mod_qos offre des réglages plus fins, mais plus complexes. Ces modules peuvent être utiles, mais ils ajoutent de la complexité et parfois des faux positifs. En 2026, beaucoup de sites préfèrent s'appuyer sur un CDN ou un reverse proxy en amont, qui gère cette protection mieux et plus tôt. Le choix dépend de votre architecture.

Le rate limiting via le reverse proxy

Si vous utilisez un reverse proxy (Nginx, HAProxy, un CDN), le rate limiting peut y être configuré. C'est souvent plus efficace qu'Apache, car le filtrage se fait en amont. Sur Apache seul, mod_ratelimit permet une limitation simple, mais limitée. Pour une vraie protection, un reverse proxy ou un WAF est souvent préférable. L'important est de décider consciemment où cette protection doit résider.

Le rôle du WAF et de mod_security

Le Web Application Firewall (WAF) est une couche supplémentaire, qui analyse les requêtes et bloque les tentatives d'attaque connues. mod_security est le WAF open source de référence pour Apache. Mais un WAF n'est pas magique, et un mauvais réglage peut faire plus de mal que de bien.

Mod_security : quand l'activer, quand s'en passer

Activer mod_security est souvent recommandé pour les applications exposées, surtout si elles sont anciennes ou peu maintenues. Mais le module ajoute une couche de traitement, ce qui coûte en performance. Et il peut bloquer du trafic légitime. Sur un site simple, avec peu de formulaires et un code moderne, le gain marginal peut ne pas justifier la complexité. À évaluer au cas par cas.

Les règles OWASP CRS et la maintenance

Le Core Rule Set d'OWASP fournit des règles génériques qui couvrent les attaques classiques (SQLi, XSS, LFI). Ces règles sont maintenues, mais elles nécessitent un réglage fin pour votre application. Le mode par défaut est souvent « détection », avec des faux positifs. Il faut ajuster les seuils, ajouter des exceptions, et surveiller les logs. Un CRS non maintenu accumule les faux positifs et finit par être désactivé, ce qui annule son intérêt.

Le coût réel d'un WAF mal réglé

Un WAF mal réglé bloque des utilisateurs légitimes, ralentit le site, et donne une fausse impression de sécurité. J'ai vu des sites avec un WAF qui bloquait les paiements, sans que personne ne s'en aperçoive pendant des jours. Le coût de ces incidents est souvent bien supérieur au gain. La règle : tester en mode détection avant d'activer le blocage, surveiller les logs, ajuster progressivement. Un WAF n'est utile que s'il est correctement entretenu.

Journaux, surveillance et alertes

La sécurité, c'est aussi la capacité à détecter et à comprendre. Sans journaux exploitables, impossible de savoir ce qui s'est passé. Et sans surveillance, impossible de réagir à temps.

Les logs nécessaires pour détecter une intrusion

access.log et error.log sont la base. access.log montre toutes les requêtes, y compris les tentatives d'attaque. error.log signale les erreurs, y compris les erreurs de sécurité. Activez un format de log qui contient l'IP, la méthode, l'URL, le code de statut et le user-agent. Ce format permet de détecter des patterns suspects. Sur un site de taille moyenne, un centralisateur de logs est vite nécessaire.

Rotation, conservation et intégrité des logs

Les logs doivent être conservés assez longtemps pour permettre une enquête en cas d'incident. logrotate automatise la rotation. La conservation de six mois à un an est courante, mais dépend de votre contexte légal. L'intégrité est importante : un attaquant qui efface ou modifie les logs complique l'enquête. Envoyer les logs vers un serveur distant, ou utiliser un service de journalisation, est une bonne pratique.

Alertes sur les erreurs répétées et les scans

Un pic soudain de 404, de 403 ou de requêtes 500 peut signaler un scan ou une attaque. Une alerte sur ces indicateurs permet une réaction rapide. Des outils comme Fail2ban analysent les logs et bannissent les IP suspectes. Un simple script peut aussi alerter sur un pic de trafic inhabituel. La surveillance n'a pas besoin d'être parfaite pour être utile : quelques alertes bien choisies font une vraie différence.

Les erreurs classiques de sécurisation

La sur-sécurisation est aussi un problème. Une configuration trop agressive casse des fonctionnalités, produit des faux positifs, et finit par être désactivée. Voici les erreurs que je vois le plus souvent.

Trop de restrictions, un site cassé

Un CSP trop strict bloque les scripts légitimes. Un WAF trop agressif bloque les formulaires. Un Options -Indexes sans réflexion casse un répertoire de téléchargement public. La bonne approche consiste à tester progressivement, en observant les effets. Une restriction utile est une restriction qui ne gêne personne, ou qui gêne de manière contrôlée.

Les en-têtes appliqués à tout, y compris aux téléchargements

Appliquer X-Frame-Options ou Content-Security-Policy à des fichiers statiques, comme des images ou des PDF, est inutile. Pire, cela peut produire des comportements bizarres dans certains contextes. Ciblez les en-têtes en fonction du type de contenu. <FilesMatch> permet ce ciblage. Un peu de précision vaut mieux qu'une application globale.

Une configuration de sécurité jamais testée en conditions réelles

La configuration valide ne garantit pas un site fonctionnel. Il faut tester les parcours utilisateurs, les formulaires, les paiements, les uploads. Une configuration qui passe configtest peut produire des erreurs à l'usage. La méthode : activer les réglages en préproduction, tester avec des utilisateurs réels, ajuster. Ne déployez jamais une modification de sécurité importante directement en production, sans période de test.

La sécurité laissée à la seule responsabilité de l'application

Le serveur web est une couche de sécurité, pas une passoire. Penser que l'application gère tout est une erreur fréquente. Le serveur peut filtrer les requêtes malformées, limiter les méthodes autorisées, bloquer les accès non légitimes. Une application sécurisée sur un serveur mal configuré est plus vulnérable qu'une application standard sur un serveur durci. La sécurité est une chaîne, et chaque maillon compte.

FAQ : les questions les plus fréquentes sur la sécurité Apache

Faut-il activer tous les en-têtes de sécurité ? Non, pas systématiquement. Certains en-têtes cassent des fonctionnalités. Le CSP demande une configuration précise, sinon il bloque le site. Les autres en-têtes (X-Content-Type-Options, X-Frame-Options, Referrer-Policy) sont plus sûrs à activer par défaut. Choisissez en fonction de votre contexte et testez.

Mod_security est-il indispensable ? Pas indispensable, mais utile sur les applications exposées. Il complète les autres mesures, il ne les remplace pas. Sur un site moderne et bien codé, le gain peut être marginal par rapport au coût de maintenance. Sur une application ancienne ou peu maintenue, il apporte une sécurité réelle. Évaluez selon votre situation.

Comment valider une configuration de sécurité ? Plusieurs niveaux. Testez d'abord avec des scanners (SSL Labs, Security Headers, observatoire de l'ANSSI). Testez ensuite avec des parcours utilisateurs réels. Vérifiez les logs après quelques jours pour détecter les faux positifs et les anomalies. Et n'oubliez pas l'audit humain : un œil extérieur repère souvent ce qu'on a oublié.

Conclusion : une sécurité progressive et documentée

Sécuriser Apache n'est pas un coup unique, c'est un processus. On commence par les réglages à fort impact et faible risque (ServerTokens, X-Content-Type-Options, durcissement TLS). On ajoute progressivement les réglages qui demandent plus de finesse (CSP, WAF, contrôle d'accès). On documente chaque décision, pour comprendre pourquoi une directive est là et ce qu'elle protège. Et on teste, encore et encore. En 2026, avec des exigences légales et des scanners de plus en plus agressifs, cette rigueur n'est plus un luxe. C'est ce qui distingue un serveur qui tient la route d'un serveur qui finit par tomber. Prenez le temps, documentez, testez, et ajustez. La sécurité, c'est un investissement, pas une dépense.