
1. Savoir ce que vous exécutez réellement
Le fait le plus utile, et le plus souvent faux. L’avis de votre gestionnaire de paquets n’est pas le binaire sur le disque, qui n’est pas le code en mémoire.2. Inventorier tous les nginx que vous avez oubliés
Le nginx que vous corrigez est rarement le seul que vous exécutez. Les conteneurs épinglent leurs propres copies, et un tag épinglé ne bouge jamais tout seul.nginx:1.30.1 épinglé est figé jusqu’à reconstruction. Si vos fichiers compose épinglent des versions exactes, corriger devient un changement de code : cela relève de votre routine de déploiement, pas de votre routine serveur.
3. Réduire ce qui est exposé
La plupart des avis nginx concernent un module ou une directive précise. Moins vous en utilisez, moins d’avis vous concernent. Commencez par voir ce que votre build embarque :map, rewrite et captures de regex :
map — c’est une bonne directive. C’est une raison de savoir en quelques secondes, plutôt qu’en un après-midi, si un avis qui la nomme vous concerne.
4. Cesser d’annoncer sa version
nginx renvoie sa version exacte dans chaque en-tête de réponse et chaque page d’erreur, par défaut. Cela transforme n’importe quel scan en liste ciblée.5. Poser les en-têtes qui ne coûtent rien
Quatre en-têtes, sans inconvénient pour l’immense majorité des sites :always compte : sans lui, les en-têtes disparaissent des réponses d’erreur, précisément celles qu’un attaquant voit le plus.

