expose_php et en-têtes Server : masquer les indications de version

En bref : avec expose_php = Off dans le php.ini, l'en-tête X-Powered-By: PHP/… disparaît. S'y ajoutent server_tokens off; dans Nginx ainsi que ServerTokens Prod et ServerSignature Off dans Apache. Cela ne rend aucun serveur plus sûr, mais retire aux analyses automatisées une liste de versions toute prête. Vous vérifiez ensuite votre propre niveau de correctifs via le gestionnaire de paquets et les processus, pas via les en-têtes.

La carte de visite dans chaque réponse

Quiconque voulait savoir, après le 21 octobre 2026, combien de serveurs affichaient encore une ancienne version de PHP n'avait pas à chercher longtemps. De nombreux serveurs web indiquent leur version de PHP dans chaque réponse, par exemple sous la forme X-Powered-By: PHP/8.2.20. Les services de recherche à l'échelle d'Internet lisent ces informations, et Unit 42 de Palo Alto Networks a dénombré pour PHP2Shell plus de 22,6 millions d'instances exposées et potentiellement vulnérables.

Pour les attaquants, une telle indication est un raccourci. Ils peuvent présélectionner les cibles au lieu d'essayer à l'aveugle. Pour les exploitants, elle est en revanche inutile, car elle ne prouve même pas leur propre niveau de correctifs : les distributions livrent souvent des corrections sous forme de backport sans nouveau numéro de version.

Cet article montre où PHP et les serveurs web divulguent des informations de version et comment désactiver ces indications. Il dit aussi franchement ce que cela apporte et ce que cela n'apporte pas.

Où les indications de version apparaissent

La version de PHP n'est qu'un endroit parmi plusieurs. Un examen complet vaut la peine, car un seul endroit oublié dévalue les autres mesures.

Les fichiers de test avec phpinfo() sont la source la plus fructueuse pour les attaquants. Ils révèlent non seulement la version, mais toute la configuration ; plus de détails dans l'article Fichiers phpinfo() : pourquoi ils doivent disparaître.

Désactiver expose_php dans le php.ini

Selon le manuel PHP, expose_php est activé par défaut et n'est modifiable que dans le php.ini, pas dans le pool, pas via .htaccess et pas à l'exécution. Définissez donc la valeur dans le php.ini de chaque mode d'exploitation qui sert des sites, donc sous Debian et Ubuntu par exemple dans /etc/php/<version>/fpm/ et, le cas échéant, /etc/php/<version>/apache2/.

; php.ini de la SAPI web, puis redémarrer PHP-FPM ou Apache
expose_php = Off

Si plusieurs versions de PHP tournent en parallèle, chacune a besoin de son entrée. Un redémarrage du service concerné est obligatoire, car PHP ne lit le php.ini qu'au démarrage.

Raccourcir les en-têtes Server dans Nginx et Apache

Nginx indique par défaut sa version dans l'en-tête Server et sur les pages d'erreur. Avec server_tokens off;, seul le nom du produit subsiste. Un en-tête X-Powered-By que l'application définit elle-même peut en outre être filtré avec fastcgi_hide_header. Selon la documentation de Nginx, Nginx ne masque de lui-même que Status et X-Accel-…, pas X-Powered-By.

# dans le bloc http, valable pour tous les sites
server_tokens off;
fastcgi_hide_header X-Powered-By;

Dans Apache, ServerTokens commande l'en-tête Server et en même temps la ligne de version sous les pages d'erreur. Selon la documentation d'Apache, le paramètre ne s'applique qu'à l'échelle du serveur, pas par VirtualHost. Comme les réponses de PHP-FPM via mod_proxy_fcgi atterrissent dans une autre table d'en-têtes que les réponses du serveur lui-même, appliquez la suppression dans les deux variantes.

# configuration à l'échelle du serveur, par ex. /etc/apache2/conf-available/security.conf
ServerTokens Prod
ServerSignature Off

# nécessite mod_headers
<IfModule mod_headers.c>
    Header unset X-Powered-By
    Header always unset X-Powered-By
</IfModule>

Vérifiez la configuration avant le rechargement avec nginx -t ou apachectl configtest. La manière d'activer activement une protection pour les visiteurs via les en-têtes, par exemple avec HSTS ou une Content-Security-Policy, est décrite dans le guide En-têtes de sécurité pour les sites web.

Vérifier le résultat de l'extérieur

Après le changement, vérifiez chaque domaine individuellement, si possible aussi une page d'erreur. Les commandes suivantes n'envoient que des requêtes normales vers vos propres sites :

# En-têtes de la page d'accueil
curl -sI https://www.example.de/ | grep -iE '^(server|x-powered-by):'
# En-têtes d'une page inexistante
curl -sI https://www.example.de/gibt-es-nicht-4711 | grep -iE '^(server|x-powered-by):'

On attend un en-tête Server sans numéro de version et aucun X-Powered-By. Si une version de PHP y figure toujours, c'est en général qu'un autre php.ini est actif ou qu'un service n'a pas encore été redémarré. Si un CDN se trouve devant le serveur, vérifiez en plus directement le serveur d'origine, dans la mesure où il est accessible.

Ce qu'apporte le masquage et ce qu'il n'apporte pas

Replacée honnêtement, la désactivation des indications de version est une petite mesure à faible coût. Elle réduit la probabilité d'apparaître dans des recherches ciblées de certaines versions et diminue les informations qu'un attaquant obtient sans effort.

Elle ne protège toutefois pas des attaques automatisées qui envoient simplement leurs requêtes à chaque serveur accessible. Le déroulement de ces analyses de masse est décrit dans l'article Analyses de masse après un PHP non corrigé. Contre PHP2Shell, seule la mise à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou un backport confirmé, aide, suivie du redémarrage de tous les processus PHP.

Un effet secondaire est en revanche très utile : qui désactive les indications de version vers l'extérieur doit recenser proprement ses versions en interne. Dans une situation comme PHP2Shell, c'est précisément cette vue d'ensemble qui détermine la rapidité avec laquelle vous savez quels serveurs sont concernés.

Le masquage a donc du sens dans le cadre d'un durcissement de base, pas comme mesure isolée. Il a sa place dans la même liste de contrôle que les sorties d'erreur désactivées, les fichiers de test supprimés et les valeurs de configuration verrouillées.

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

• Recenser les emplacements : nous examinons les en-têtes, pages d'erreur et racines web de tous les domaines à la recherche d'indications de version et de fichiers de test oubliés.
• Adapter la configuration : nous définissons expose_php, les en-têtes Server et les filtres d'en-têtes dans chaque version de PHP et chaque serveur web, et redémarrons les services de façon contrôlée.
• Prouver le niveau de correctifs en interne : nous documentons versions et états des paquets là où ils doivent être, dans l'inventaire plutôt que dans l'en-tête HTTP.
• L'intégrer au durcissement : la mesure fait partie de notre durcissement de serveur pour serveurs web PHP.

Questions fréquentes

Sources

• Manuel PHP : directives du noyau (expose_php)
• Nginx : server_tokens (ngx_http_core_module)
• Apache : ServerTokens et ServerSignature
• OWASP Cheat Sheets