Skip to main content
Auditer et durcir nginx sur un VPS : connaître sa version, réduire la surface, vérifier Publié le 12 août 2026 Deux débordements de tas sont apparus dans le moteur de script de nginx à quelques mois d’intervalle cette année, et le second a pris de court quantité de gens qui avaient déjà corrigé le premier. Ce n’est pas un échec de correction. C’est un échec d’inventaire : ne pas savoir précisément ce qu’on exécute, et où. Voici la routine qui règle ça. Une vingtaine de minutes la première fois, deux minutes par mois ensuite.

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.
Si la troisième commande montre un processus maître plus ancien que votre dernière mise à jour, vous avez installé un correctif sans jamais redémarrer. L’ancien binaire sert toujours le trafic. C’est l’écart le plus fréquent entre « corrigé » et « sûr ».
nginx -s reload ne remplace pas le processus maître. Après une mise à jour de paquet, utilisez systemctl restart nginx. Le rechargement sert aux changements de configuration, pas de binaire.

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.
Un 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 :
Puis regardez ce que votre configuration sollicite réellement. Les deux débordements de tas de cette année vivaient tous deux dans le moteur de script — map, rewrite et captures de regex :
Ce n’est pas une raison d’éviter 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.
Ce n’est pas un contrôle de sécurité — cela ne corrige aucun bug. C’est un contrôle de coût : cela vous sort de l’ensemble trivialement énumérable, là où l’exploitation de masse fait ses courses. Vérifiez que c’est pris en compte :

5. Poser les en-têtes qui ne coûtent rien

Quatre en-têtes, sans inconvénient pour l’immense majorité des sites :
Strict-Transport-Security est un engagement. Une fois qu’un navigateur l’a vu, il refuse le HTTP simple sur votre domaine pendant toute la durée du max-age. Ne l’ajoutez que si HTTPS fonctionne partout sur le domaine, sous-domaines compris, et commencez avec un max-age court en cas de doute.
Le mot-clé always compte : sans lui, les en-têtes disparaissent des réponses d’erreur, précisément celles qu’un attaquant voit le plus.

6. Plafonner la taille et le débit des requêtes

Les valeurs par défaut sont généreuses parce que nginx ne connaît pas votre application. Un point d’envoi qui accepte 1 Go quand votre plus gros fichier légitime pèse 5 Mo, c’est des munitions offertes.
Ajustez les chiffres à votre application plutôt que de les recopier. Ce qui compte, c’est qu’un chiffre existe.

7. Vérifier, puis en faire une routine

Ne rechargez jamais sur une configuration non testée :
Puis réduisez tout l’audit à une commande à lancer chaque mois :

Ce que cela vous apporte vraiment

Rien de tout cela n’empêchera le prochain débordement de tas dans le moteur de script. Aucune configuration ne le fera. Ce que cela apporte, c’est de pouvoir répondre en moins d’une minute à la seule question que pose réellement un avis : la version que j’exécute est-elle dans la plage touchée, partout où je l’exécute ? Les équipes qui savent y répondre corrigent en un après-midi. Les autres passent une semaine à le découvrir, et oublient généralement un conteneur. Deux habitudes portent l’essentiel : redémarrer après une mise à jour de paquet, et traiter les tags de conteneurs épinglés comme du code à mettre à jour. À lire aussi : notre avis sur les deux débordements de tas de nginx et le guide de sécurité renforcée pour VPS pour la couche du dessous. Une question sur un serveur hébergé chez nous ? Notre équipe est disponible depuis votre espace client.