Informations divulguées

Certains headers de réponse n'existent que pour annoncer les logiciels que vous exécutez. Server nomme le serveur web, souvent avec sa version exacte et son système d'exploitation. X-Powered-By nomme le langage ou le framework du backend. Derrière ces deux-là s'étend une longue traîne de headers propres aux éditeurs qui nomment le CMS, le cache, l'agent de supervision ou une machine interne. Aucun d'eux ne change la façon dont le navigateur affiche la page.

Ce qu'ils font, c'est offrir à un attaquant une empreinte gratuite de votre stack, prête à être recherchée dans les bases de CVE pour y trouver des exploits connus. Le correctif coûte une ligne de configuration par header : le supprimer, ou, là où le serveur refuse de le retirer, le réduire à une valeur générique sans version.

HTTP/1.1 200 OK
Server: Apache/2.4.41 (Unix)
X-Powered-By: PHP/8.2.1
Content-Type: text/html; charset=utf-8

HTTP/1.1 200 OK
Server: Apache
Content-Type: text/html; charset=utf-8

Pourquoi les bannières comptent

Prendre l'empreinte du serveur web est une première étape formelle d'un test d'intrusion. Le guide de test de l'OWASP (WSTG-INFO-02, Fingerprint Web Server) appelle la technique le banner grabbing : envoyer une requête, lire les headers de réponse. Un header comme Server: Apache/2.4.41 (Unix) répond à l'essentiel de la reconnaissance en une ligne, et, comme le dit le guide, les serveurs qui font tourner d'anciennes versions de logiciels sans correctifs de sécurité à jour peuvent être vulnérables à des exploits connus propres à ces versions.

Le processus est mécanique. Une bannière de version exacte, disons X-Powered-By: PHP/5.3.7, part directement dans une recherche de base de CVE, qui renvoie la liste des vulnérabilités connues de cette version. Certains headers de divulgation en révèlent plus qu'une version. Les réponses de Microsoft Exchange peuvent transporter les noms de serveurs front-end et back-end internes (X-FEServer, X-BEServer, X-CalculatedBETarget), cartographiant la même surface de routage front-end vers back-end dont la chaîne d'exploitation ProxyLogon (CVE-2021-26855, analysée par Google Project Zero) a abusé.

Soyez toutefois honnête sur le poids de ce constat. MDN qualifie le masquage du header Server de mesure au bénéfice discutable, parce que les attaquants peuvent prendre l'empreinte d'une stack par d'autres moyens, et indique que l'approche la plus fiable consiste à garder le logiciel à jour et corrigé. Les bonnes pratiques de sécurité d'Express disent la même chose de la désactivation de X-Powered-By : elle n'empêche pas un attaquant chevronné d'identifier le framework. Retirer les bannières coupe le vecteur de reconnaissance le moins coûteux et fait disparaître les constats que remontent chaque scanner et chaque rapport de test d'intrusion ; la défense qui compte vraiment, c'est l'application des correctifs.

Les headers à supprimer

Chaque header des tableaux ci-dessous reçoit le même conseil, le supprimer, il n'y a donc pas de colonne de statut. L'inventaire de référence est la liste de suppression de l'OWASP Secure Headers Project, 81 headers dans sa mise à jour du 30 juin 2026, sur laquelle s'appuient les scanners et les rapports de test d'intrusion. Les tableaux regroupent les entrées les plus courantes par ce qu'elles révèlent ; lorsqu'un header est signalé par la communauté plutôt que documenté officiellement, la description le précise.

Bannières de serveur, de langage et de framework

Versions de CMS et de plateforme

Empreintes d'infrastructure et de cache

Noms d'hôtes internes

Les serveurs front-end d'Exchange ajoutent des headers de routage aux réponses d'Outlook Web Access et d'autodiscover. Ils révèlent des noms de machines internes, ce qui relève de la divulgation de topologie plutôt que d'une bannière de version, et ils se trouvent sur la même surface de routage front-end vers back-end dont ProxyLogon a abusé.

Agents de supervision

La famille OneAgent de Dynatrace marque les réponses qu'elle a touchées, indiquant à un attaquant exactement quelle stack de supervision surveille le site.

Artefacts de développement et de débogage

Ceux-ci vont au-delà de la prise d'empreinte : chacun signifie qu'un élément du développement a atteint la production.

Comment les supprimer

Chaque stack dispose d'un interrupteur pour ses propres bannières. Tout ce que votre application ou votre framework ajoute par-dessus peut être retiré par ce qui se trouve devant, un reverse proxy ou un CDN.

nginx

server_tokens off;
proxy_hide_header X-Powered-By;

Dans nginx, server_tokens off masque la version à la fois dans le header Server et dans les pages d'erreur intégrées, mais le header affiche toujours Server: nginx. Le retirer entièrement nécessite le module tiers headers-more (more_clear_headers Server;). En mode proxy, nginx remplace déjà le header Server de l'amont par le sien ; proxy_hide_header retire au passage les headers applicatifs tels que X-Powered-By.

Apache

ServerTokens Prod
ServerSignature Off
Header always unset X-Powered-By

Dans Apache, ServerTokens Prod réduit la bannière à Server: Apache et ServerSignature Off retire le pied de page de version des pages d'erreur. Notez que Header unset Server ne retire pas le header Server propre à Apache (Apache Bug 40026) ; mod_headers ne peut retirer que les headers ajoutés par l'application, comme X-Powered-By.

IIS et ASP.NET

<configuration>
  <system.web>
    <httpRuntime enableVersionHeader="false" />
  </system.web>
  <system.webServer>
    <security>
      <requestFiltering removeServerHeader="true" />
    </security>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Sur IIS 10 et versions ultérieures, removeServerHeader retire complètement le header Server (Windows Server version 1709 et ultérieures). enableVersionHeader="false" supprime X-AspNet-Version, et le bloc customHeaders retire X-Powered-By. La bannière de version MVC a son propre interrupteur, défini au démarrage de l'application :

MvcHandler.DisableMvcResponseHeader = true;

Express

app.disable('x-powered-by');

Les bonnes pratiques de sécurité d'Express recommandent cette ligne, ou d'utiliser Helmet, qui retire le header en même temps que ses autres modifications de headers.

PHP

expose_php = Off

expose_php ne peut être défini que dans php.ini, pas à l'exécution.

Next.js

module.exports = {
  poweredByHeader: false,
};

L'option poweredByHeader empêche Next.js d'envoyer X-Powered-By.

En périphérie, au CDN ou au proxy

La périphérie peut retirer ce que l'origine ne peut pas. Sur Cloudflare, une règle de transformation de headers de réponse avec l'opération de suppression efface n'importe lequel de ces headers avant que la réponse n'atteigne le visiteur, avec une réserve : elle ne peut pas retirer les headers préfixés cf- ou x-cf-, ni le header server propre à Cloudflare. Un reverse proxy ou un cache que vous exploitez vous-même, comme Varnish, peut de la même façon retirer des headers de réponse dans sa logique de livraison. C'est souvent le correctif le plus rapide pour les headers d'éditeurs pour lesquels une plateforme managée ne vous offre aucun interrupteur.

Peut-on retirer entièrement le header Server

Cela dépend du serveur. IIS 10 et versions ultérieures le peuvent, avec removeServerHeader. Un nginx standard ne le peut pas : server_tokens off envoie encore Server: nginx, et le retrait complet nécessite le module headers-more. Apache ne le peut pas non plus ; ServerTokens Prod et son plancher Server: Apache sont tout ce que permet la configuration de base. Derrière un CDN, la question disparaît souvent, parce que la périphérie substitue sa propre bannière (Cloudflare envoie server: cloudflare, que vous ne pouvez pas retirer). Un simple nom de produit sans version est un état final tout à fait acceptable ; c'est la version qui alimente la recherche de CVE.

Recommandation

Supprimez ou banalisez chaque header des tableaux ci-dessus. Le cheat sheet OWASP sur les headers HTTP le dit sans détour : pour Server, « supprimez ce header ou définissez des valeurs non informatives », et « supprimez tous les headers X-Powered-By ». Utilisez la liste de suppression de l'OWASP Secure Headers Project comme check-list quand vous passez vos réponses en revue.

Gardez ce constat en perspective. Supprimer une bannière ne corrige rien ; si le logiciel derrière est obsolète, il est exactement aussi exploitable après. Faites ce nettoyage comme une mesure d'hygiène en parallèle des correctifs, pas à leur place. Pour voir lesquels de ces headers votre site envoie aujourd'hui, passez-le dans le scanner de headers de sécurité.

FAQ

Comment supprimer X-Powered-By ?

Cela dépend de ce qui l'émet. En PHP, réglez expose_php = Off ; dans Express, appelez app.disable('x-powered-by') ; dans Next.js, réglez poweredByHeader: false ; dans IIS, retirez-le via customHeaders. Quand vous ne pouvez pas modifier l'origine, retirez-le au reverse proxy ou au CDN, par exemple proxy_hide_header X-Powered-By dans nginx.

Le header Server est-il une vulnérabilité ?

Pas en lui-même. C'est un constat de divulgation d'information : la bannière de version indique à un attaquant quel logiciel et quelle version chercher dans une base de CVE, ce qui supprime l'étape de reconnaissance la moins coûteuse. Le vrai risque, c'est de faire tourner un logiciel non corrigé derrière la bannière. Le retirer fait taire les scanners mais ne corrige rien.

Masquer les bannières de version rend-il mon site sûr ?

Non. Retirer Server, X-Powered-By et les autres bannières est une réduction du bruit : cela supprime le vecteur de prise d'empreinte le plus facile et fait disparaître des constats de scanner. Cela ne corrige pas une seule faille sous-jacente. Comme le notent OWASP et MDN, garder le logiciel corrigé est la vraie défense ; le retrait des bannières est une mesure d'hygiène à côté.

Voir aussi

• Vue d'ensemble des headers de sécurité
• Headers dépréciés, l'autre page dont toute la réponse est de supprimer : les headers TLS morts HPKP et Expect-CT
• Scanner de headers de sécurité pour vérifier vos headers déployés

Sources

• OWASP WSTG-INFO-02, Fingerprint Web Server
• OWASP Secure Headers Project, headers à supprimer
• OWASP, cheat sheet des headers HTTP
• MDN, Server
• MDN, SourceMap
• nginx, ngx_http_core_module (server_tokens)
• Apache, directives core (ServerTokens, ServerSignature)
• IIS, référence requestFiltering
• Express, bonnes pratiques de sécurité
• Manuel PHP, directives core de php.ini (expose_php)
• Next.js, référence de configuration poweredByHeader
• Google Project Zero, analyse de cause racine de CVE-2021-26855