Sommaire
Introduction
La sécurité web est aujourd’hui un enjeu fondamental. Face à la montée des attaques (XSS, clickjacking, vol de session…), les administrateurs système doivent renforcer la protection de leurs serveurs. Dans ce contexte, les headers HTTP de sécurité représentent une première ligne de défense simple, rapide à mettre en place et très efficace.
Dans cet article, nous allons découvrir comment sécuriser un serveur Nginx grâce aux en-têtes recommandés par l’OWASP. Nous détaillerons également leur fonctionnement, leur impact sur le comportement du navigateur, et leur intégration propre dans la configuration du serveur.
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=31536000correspond à une durée d’un an.includeSubDomainsapplique 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 :
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.
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.
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.
Quelques conseils :
- Toujours tester sur un environnement de staging.
- Ajuster les directives
script-src,style-src,img-srcdans la CSP. - Ajouter
unsafe-inlineuniquement 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.
