Scanner de fuites dans les en-têtes

Comment fonctionne cette vérification

Scanaris lit les en-têtes de la réponse principale de ta page et en regarde deux en particulier. Si X-Powered-By est présent avec n'importe quelle valeur (par exemple Express, PHP/8.2.12 ou Next.js), il ouvre un constat de sévérité faible. Si Server est présent et que sa valeur contient un numéro de version (quelque chose comme nginx/1.18.0 ou Apache/2.4.57), il en ouvre un autre. Un simple Server: nginx ou Server: cloudflare n'est pas signalé : dire quel serveur tu utilises n'est pas un problème ; dire exactement quelle version, si.

Pourquoi c'est important

Aucun de ces deux en-têtes n'apporte quoi que ce soit à l'utilisateur ou au navigateur. Ils existent par habitude. Ce qu'ils font, c'est épargner du travail à celui qui cherche une vulnérabilité : avec PHP/7.4.3 ou Apache/2.4.49 dans la réponse, l'attaquant n'a rien à deviner, il va directement à la liste des failles connues de cette version et essaie celles qui ont un exploit public. C'est un constat de sévérité faible parce qu'à lui seul il n'ouvre aucune porte ; mais c'est l'un des plus faciles à fermer, et les scanners de masse filtrent leurs cibles exactement sur ces en-têtes.

Comment les retirer selon ta stack

• Express : app.disable('x-powered-by') à la création de l'app, ou utilise helmet(), qui le retire avec d'autres durcissements.
• Next.js : envoie X-Powered-By: Next.js par défaut. Dans next.config.js, poweredByHeader: false.
• PHP : dans php.ini, expose_php = Off. En hébergement mutualisé, ça se change généralement depuis le panneau ou avec un .user.ini.
• ASP.NET : dans web.config, sous customHeaders, <remove name="X-Powered-By" />, et dans IIS désactive aussi l'en-tête X-AspNet-Version avec enableVersionHeader="false".
• nginx : server_tokens off; dans le bloc http. Il dit toujours « nginx », mais sans version.
• Apache : ServerTokens Prod et ServerSignature Off dans la configuration principale. Avec Prod, l'en-tête devient simplement Apache.
• Vercel, Netlify, Cloudflare Pages : n'envoient pas de version dans Server. Si tu vois X-Powered-By là, il vient de ton framework (Next.js ou Express), pas de la plateforme.

Si tu as un proxy ou un CDN devant (Cloudflare, un équilibreur), vérifie la réponse publique : parfois le proxy remplace l'en-tête Server et le problème disparaît tout seul, mais X-Powered-By passe généralement intact.

Vérifie que c'est corrigé

curl -sI https://tondomaine.com | grep -iE "^(server|x-powered-by):"

L'idéal est que X-Powered-By n'apparaisse pas et que Server, s'il apparaît, ne porte pas de numéro. Essaie aussi une route d'API ou une page d'erreur (une URL qui n'existe pas) : les erreurs sont parfois générées dans une autre couche qui remet l'en-tête.

Questions fréquentes

Cacher la version ne corrige pas la vulnérabilité. À quoi ça sert ?

À ne pas figurer sur la première page de résultats de celui qui cherche des victimes. Tu as raison : la vraie solution est de mettre à jour ; cacher la version est le complément, pas le substitut. Les deux ensemble prennent cinq minutes.

Mon hébergeur ne me laisse pas toucher à la configuration du serveur.

Dans ce cas, retire au moins X-Powered-By depuis ton code ou ton .htaccess (Header unset X-Powered-By) et demande à l'hébergeur de masquer la version. Les autres en-têtes de sécurité, ceux que tu devrais avoir, sont passés en revue par la vérification en-têtes de sécurité.

Pourquoi « Server: cloudflare » n'est-il pas signalé ?

Parce qu'il ne révèle rien d'exploitable : ni version ni logiciel précis derrière. Ce qu'on cherche ici, c'est de l'information qui raccourcit le chemin vers un exploit. Quels en-têtes valent la peine et lesquels sont du bruit, c'est dans les en-têtes HTTP expliqués aux humains.