Configurer Apache pour PHP en toute sécurité

En bref : pour configurer Apache pour PHP en toute sécurité, connectez PHP via PHP-FPM et mod_proxy_fcgi, désactivez .htaccess avec AllowOverride None et définissez ServerTokens Prod, ServerSignature Off, TraceEnable Off et Options -Indexes. Adaptez LimitRequestBody aux limites de PHP et désactivez les modules inutiles. La configuration ne remplace pas une mise à jour de PHP, mais réduit nettement la surface d'attaque.

Apache après PHP2Shell : plus qu'un redémarrage

En octobre 2026, les exploitants d'Apache étaient sous une pression particulière. L'équipe PHP évalue le risque de mod_php comme le plus élevé, parce qu'un exploit y a été démontré avant même que le code de l'application ne s'exécute. Les étapes urgentes, c'est-à-dire corriger et redémarrer complètement, sont décrites sur la page Pourquoi mod_php porte le risque le plus élevé.

Après le correctif, reste la question de la qualité de la configuration d'Apache elle-même. Les serveurs qui ont grandi portent souvent des paramètres accumulés pendant de nombreuses années : listes de répertoires, droits .htaccess ouverts, modules dont plus personne n'a besoin. Chacun de ces éléments peut aggraver une erreur ultérieure plus qu'elle ne devrait l'être.

Cet article décrit une configuration de base épurée et sûre pour Apache 2.4 avec PHP-FPM. Les exemples utilisent les chemins de Debian et Ubuntu ; sur la famille RHEL, les fichiers se trouvent sous /etc/httpd/.

Connecter PHP via PHP-FPM plutôt que mod_php

Avec PHP-FPM, PHP s'exécute dans ses propres processus, séparés du serveur web. Apache transmet les requêtes via mod_proxy_fcgi. Selon la documentation d'Apache, la connexion par SetHandler présente un avantage par rapport à ProxyPassMatch : Apache associe d'abord lui-même la requête à un fichier du système de fichiers, et ne la transmet qu'ensuite à PHP-FPM.

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
</FilesMatch>

Sous Debian et Ubuntu, vous activez les modules avec a2enmod proxy_fcgi. Qui abandonne mod_php désactive le module PHP, puis passe du MPM Prefork au MPM Event. Les arrière-plans de l'ancien mode d'exploitation sont expliqués dans mod_php expliqué : PHP dans le processus Apache.

Côté PHP-FPM, security.limit_extensions = .php a sa place dans chaque pool. Selon le manuel PHP, FPM exécute sinon aussi les fichiers .phar.

Configurer Apache pour PHP en sécurité : les options du noyau

Certains paramètres s'appliquent à tout le serveur et ont leur place dans un fichier de configuration dédié, par exemple /etc/apache2/conf-available/haertung.conf, activé avec a2enconf haertung.

# Raccourcir les indications de version (possible uniquement à l'échelle du serveur)
ServerTokens Prod
ServerSignature Off

# Désactiver la méthode TRACE
TraceEnable Off

# Ne rien autoriser par principe, autoriser les sites de façon ciblée
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Le tableau suivant classe les options les plus importantes. Les valeurs par défaut et leur effet proviennent de la documentation d'Apache.

Important pour AllowOverride : de nombreuses distributions et tutoriels de CMS définissent AllowOverride All pour la racine web. Ainsi, n'importe quel fichier .htaccess peut modifier des règles de réécriture, des handlers et, avec mod_php, même des paramètres PHP. Un attaquant disposant de droits d'écriture dans un dossier d'upload peut y déposer son propre .htaccess. Avec AllowOverride None, cette voie est fermée.

Un VirtualHost comme modèle

Le VirtualHost suivant rassemble les points pour un site donné. Adaptez les chemins des certificats, le socket et les répertoires. mod_ssl et mod_headers doivent être actifs.

<VirtualHost *:443>
    ServerName www.example.de
    DocumentRoot /var/www/seite1/public

    SSLEngine on
    SSLCertificateFile    /etc/ssl/seite1/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/seite1/privkey.pem

    <Directory /var/www/seite1/public>
        Options -Indexes +SymLinksIfOwnerMatch
        AllowOverride None
        Require all granted
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
    </FilesMatch>

    # Bloquer la gestion de versions et les fichiers d'environnement
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, en cohérence avec post_max_size = 32M
    LimitRequestBody 33554432

    Header unset X-Powered-By
    Header always unset X-Powered-By
</VirtualHost>

Le double Header unset n'est pas une erreur. Selon la documentation d'Apache, les en-têtes de mod_proxy_fcgi atterrissent dans une autre table interne que les en-têtes du serveur lui-même ; avec les deux variantes, vous couvrez les deux cas. D'autres en-têtes qui protègent activement les visiteurs sont décrits dans le guide En-têtes de sécurité pour les sites web.

Les dossiers d'upload et de cache nécessitent en plus un blocage de l'exécution. La manière de trouver et de bloquer tous les dossiers accessibles en écriture est décrite dans Interdire l'exécution de PHP dans les dossiers d'upload.

Faire le tri dans les modules et vérifier le résultat

Chaque module chargé est du code qui réagit aux requêtes. Vérifiez quels modules sont actifs et désactivez ce dont vous n'avez pas besoin. Candidats typiques : autoindex, status sans restriction d'accès, cgi et userdir.

# Afficher les modules actifs
apachectl -M | sort
# Exemple Debian/Ubuntu : désactiver le module de listes de répertoires
sudo a2dismod autoindex
# Vérifier la configuration et ne recharger qu'ensuite
sudo apachectl configtest && sudo systemctl reload apache2
# Test de l'extérieur : TRACE doit renvoyer 405, .git 403
curl -s -o /dev/null -w "%{http_code}\n" -X TRACE https://www.example.de/
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD

mod_status mérite une attention particulière. La page de statut montre les requêtes en cours avec les adresses et les chemins appelés. Si elle est nécessaire, restreignez l'accès avec Require ip à vos réseaux d'administration. Il en va de même pour les pages de statut de PHP-FPM rendues accessibles via Apache.

Un pare-feu applicatif web dédié peut être judicieux comme couche supplémentaire devant l'application ; une introduction se trouve dans Mettre en œuvre ModSecurity et l'OWASP Core Rule Set.

Conclusion : l'ordre l'emporte sur la mesure isolée

Une configuration Apache sûre pour PHP se compose de quelques éléments bien compris. PHP tourne via PHP-FPM séparément du serveur web, .htaccess n'est pas évalué, les indications de version et TRACE sont désactivés, les limites de taille correspondent à PHP, et les dossiers accessibles en écriture n'exécutent aucun script. Aucun de ces points n'est spectaculaire en soi. Ensemble, ils font en sorte qu'une erreur à un endroit n'entraîne pas immédiatement la prise de contrôle du serveur.

Pour la direction et les responsables de projet, une seconde propriété est presque plus importante : une configuration ordonnée est compréhensible. Quand toutes les règles se trouvent dans le VirtualHost au lieu d'être dispersées dans des dizaines de fichiers .htaccess, il est facile de vérifier, lors de la prochaine faille critique, quel site est connecté comment. Dans une situation comme celle d'octobre 2026, cela économise exactement le temps qui compte.

Planifiez malgré tout le changement avec calme et un environnement de test. Un passage précipité de mod_php à PHP-FPM juste avant un week-end crée plutôt de nouveaux problèmes qu'il n'en résout.

Comment PHP SOS aide-t-il concrètement ?

• Vérifier l'existant : nous lisons toute la configuration d'Apache, tous les modules actifs et tous les fichiers .htaccess.
• Planifier la transition : là où mod_php tourne encore, nous préparons le passage à PHP-FPM avec des pools dédiés par site.
• Durcir la configuration : nous définissons les options du noyau, reprenons les règles .htaccess dans les VirtualHosts et bloquons les dossiers accessibles en écriture.
• Tester et documenter : après chaque modification, nous vérifions les sites de l'extérieur et consignons l'état dans le cadre du durcissement de serveur.

Questions fréquentes

Sources

• Apache : fonctionnalités du noyau (core)
• Apache : mod_proxy_fcgi
• Apache : mod_headers
• php.net : avis de sécurité