Comment renforcer la sécurité de Nginx avec les headers HTTP essentiels

💡 TL;DR

• Sécuriser Nginx avec les headers HTTP recommandés par l’OWASP
• Protection contre XSS, clickjacking et vol de session
• Exemples de configuration concrets et bonnes pratiques

Table des matières

Pourquoi les headers HTTP sont importants

Chaque fois que votre serveur web répond à une requête, il envoie des métadonnées HTTP. Certains de ces en-têtes peuvent guider le comportement du navigateur et restreindre certaines fonctionnalités sensibles, comme l’exécution de scripts, l’affichage en iframe ou encore la détection automatique du type de contenu.

En configurant correctement ces headers, vous réduisez la surface d’attaque de votre site sans modifier une seule ligne de code côté frontend.

Les headers de sécurité recommandés par l’OWASP

1. Strict-Transport-Security (HSTS)

Ce header indique au navigateur qu’il doit toujours utiliser HTTPS pour se connecter à votre site. Il empêche également les attaques de type « downgrade » où un attaquant forcerait l’utilisateur à passer par HTTP.

Exemple à ajouter dans Nginx :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

• max-age=31536000 correspond à une durée d’un an.
• includeSubDomains applique la règle à tous les sous-domaines.

2. X-Frame-Options

Ce header bloque l’affichage de votre site dans une iframe, ce qui empêche les attaques de type clickjacking.

Exemple :

add_header X-Frame-Options "SAMEORIGIN";

Vous pouvez aussi utiliser DENY pour interdire toutes les iframes, ou ALLOW-FROM (déprécié).

3. X-Content-Type-Options

Ce header empêche le navigateur de deviner le type MIME d’un fichier et d’exécuter du code inattendu.

Exemple :

add_header X-Content-Type-Options "nosniff";

4. Referrer-Policy

Contrôle les informations du champ « Referer » pour éviter les fuites de données lors de la navigation entre sites.

Exemple :

add_header Referrer-Policy "strict-origin-when-cross-origin";

Configuration type à intégrer dans Nginx

Voici un exemple complet de bloc Nginx sécurisé :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Ce bloc est à placer dans votre bloc server {} dans Nginx, ou dans un include commun si vous gérez plusieurs hôtes virtuels.

Tester votre configuration

Pour valider que vos headers sont bien envoyés par le serveur, vous pouvez utiliser les outils suivants :

• https://securityheaders.com
• https://observatory.mozilla.org

Ces outils analysent vos en-têtes HTTP et vous attribuent une note de sécurité (de F à A+). Avec les headers recommandés ici, vous pouvez facilement atteindre un score de B ou A.

Headers supplémentaires : Content-Security-Policy (CSP)

Le header Content-Security-Policy (CSP) permet de spécifier quelles ressources peuvent être chargées par votre site (images, scripts, styles, etc.). Il s’agit d’un rempart très efficace contre les attaques XSS. C’est le header le plus délicat du lot, au point qu’il mérite son propre guide : configurer une CSP dans Nginx sans casser le site.

Exemple CSP équilibrée :

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:;" always;

Cette configuration permet :

• De charger les scripts et styles depuis le site lui-même ou via HTTPS.
• De conserver le bon fonctionnement de frameworks frontend (ex. Bootstrap, jQuery, VueJS, etc.).

Plus d’infos : https://developer.mozilla.org/fr/docs/Web/HTTP/CSP

Autre en-tête recommandé : Permissions-Policy

Ce header remplace l’ancien Feature-Policy. Il permet de contrôler l’accès aux APIs comme la caméra, la géolocalisation, le micro, etc. Couplé au rate limiting, il constitue l’étape suivante du durcissement, détaillée dans Permissions-Policy et protection anti-bots sur Nginx.

Exemple :

add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), fullscreen=(self)" always;

Plus d’infos : https://developer.mozilla.org/en-US/docs/Web/HTTP/Permissions_Policy

Sécurité et compatibilité : trouver le bon équilibre

Il est essentiel de tester chaque en-tête avant sa mise en production. Une politique trop restrictive peut bloquer des fonctionnalités vitales, notamment sur les sites modernes utilisant des frameworks JS ou des CDN tiers. Les headers ne dispensent d’ailleurs pas de verrouiller le système de fichiers : voir protéger les fichiers sensibles et les uploads sur Nginx.

Quelques conseils :

• Toujours tester sur un environnement de staging.
• Ajuster les directives script-src, style-src, img-src dans la CSP.
• Ajouter unsafe-inline uniquement si vraiment nécessaire, avec des commentaires en code pour l’identifier.

Cas d’usage : mutualisation Nginx pour plusieurs utilisateurs

Dans un contexte éducatif ou multi-utilisateur, on peut mutualiser la sécurité sur plusieurs sous-répertoires grâce aux expressions régulières dans Nginx.

Exemple de bloc :

location ~ ^/([a-z0-9-]+)(/.*)?$ {
    root /home/app/htdocs;
    try_files $uri $uri/ /$1/index.php?$args;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";
    add_header Referrer-Policy "strict-origin-when-cross-origin";
}

Cette méthode est idéale pour sécuriser tous les espaces utilisateurs sans répéter le code pour chaque location.

Conclusion

Les headers HTTP de sécurité sont des outils puissants, simples à mettre en œuvre et très efficaces. Ils renforcent la confiance des navigateurs, limitent les attaques classiques, et améliorent instantanément votre score de sécurité.

En suivant ce guide, vous pouvez :

• Améliorer votre note sur securityheaders.com
• Appliquer les bonnes pratiques OWASP
• Protéger les utilisateurs finaux sans nuire à l’expérience

Dans le prochain article, nous verrons comment configurer une Content-Security-Policy (CSP) efficace sans casser votre frontend.