NEWInfogérance serveur Linux à 119 €/mois HT — sauvegardes testées, monitoring inclus.OFFREFrais d'installation offerts pour tout engagement ferme de 12 mois.SÉCURITÉDurcissement serveur : 5 règles à appliquer ce mois-ci. Guide gratuit sur demande.MONITORINGAlertes 24/7 sur vos sites et serveurs — surveillance continue par un technicien.CONSEILSauvegardes : testées ou supposées ? On teste la restauration chaque mois pour vous.VEILLEVeille CVE proactive : on lit, on teste, on patch — avant vos clients.NEWInfogérance serveur Linux à 119 €/mois HT — sauvegardes testées, monitoring inclus.OFFREFrais d'installation offerts pour tout engagement ferme de 12 mois.SÉCURITÉDurcissement serveur : 5 règles à appliquer ce mois-ci. Guide gratuit sur demande.MONITORINGAlertes 24/7 sur vos sites et serveurs — surveillance continue par un technicien.CONSEILSauvegardes : testées ou supposées ? On teste la restauration chaque mois pour vous.VEILLEVeille CVE proactive : on lit, on teste, on patch — avant vos clients.
[ Infrastructure ]

Nginx : appliquer les recommandations ANSSI pour un reverse proxy

OWL SYSTEMS29 oct. 20262 min
Nginx : appliquer les recommandations ANSSI pour un reverse proxy

Nginx est le serveur web et reverse proxy le plus utilisé au monde. Cependant, sa configuration par défaut est pensée pour la compatibilité et la performance, pas nécessairement pour la sécurité. Pour exposer une application en production, il est indispensable d'appliquer les recommandations de l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) pour durcir le service.

1. Masquer la version et les informations système

La première étape consiste à ne pas faciliter la tâche des attaquants. Par défaut, Nginx affiche sa version dans les réponses HTTP et les pages d'erreur. Masquez ces informations en ajoutant la directive suivante dans votre bloc `http` ou `server` :

server_tokens off;

2. Durcir le protocole TLS (Chiffrement)

L'ANSSI recommande de désactiver les protocoles obsolètes (TLS 1.0 et 1.1) et de privilégier TLS 1.2 et TLS 1.3. Utilisez des suites de chiffrement fortes et activez HSTS (HTTP Strict Transport Security) pour forcer les navigateurs à n'utiliser que des connexions sécurisées.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

3. Ajouter les en-têtes de sécurité HTTP

Les en-têtes de sécurité sont des directives envoyées au navigateur pour l'empêcher d'exécuter des actions dangereuses. Ils constituent une deuxième ligne de défense contre les failles XSS ou le clickjacking.

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self';" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

4. Limiter la taille des requêtes et le Rate Limiting

Pour éviter qu'un attaquant ne sature vos ressources (DDoS applicatif) ou n'envoie des fichiers malveillants massifs, il faut brider Nginx. Limitez la taille maximale du corps des requêtes (`client_max_body_size`) et mettez en place des zones de limitation de requêtes (`limit_req_zone`) pour bloquer les clients trop insistants.

# Dans le bloc http
limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;

# Dans le bloc server
client_max_body_size 10M;
limit_req zone=one burst=10 nodelay;
La sécurité par défaut n'existe pas ; elle se configure. Un reverse proxy bien réglé est votre meilleur rempart avant même d'atteindre votre code applicatif.

Ces quelques directives transforment un serveur Nginx standard en un reverse proxy robuste, capable d'encaisser des attaques basiques et de protéger vos applications en amont. N'oubliez pas de valider votre configuration (`nginx -t`) avant de recharger le service pour éviter toute interruption.

Lire la suite