Headers de sécurité HTTP : HSTS, Permissions-Policy et les autres

Chaque réponse envoyée par votre serveur peut contenir des instructions destinées au navigateur : forcer HTTPS, interdire l'affichage du site dans un cadre, limiter l'accès à la caméra… Ces headers de sécurité, ou en-têtes de sécurité, ne coûtent rien en performance et bloquent des familles entières d'attaques. Pourtant, la majorité des sites n'en configurent aucun. Voici ceux qu'il faut connaître, avec une configuration prête à l'emploi pour nginx.

Pourquoi les headers de sécurité comptent

Les navigateurs modernes disposent de nombreux mécanismes de protection, mais beaucoup ne s'activent que si le site le demande. Sans instruction, le navigateur adopte un comportement permissif pour ne pas casser les anciens sites. Les headers de sécurité indiquent ce que votre site autorise réellement, et tout le reste est refusé.

Ils complètent les autres protections : un code sans faille (voir les vulnérabilités OWASP), des mises à jour régulières et un serveur bien configuré.

Strict-Transport-Security (HSTS)

Même avec une redirection de HTTP vers HTTPS, la toute première requête d'un visiteur qui tape votre adresse sans https:// part en clair. Sur un Wi-Fi public, un attaquant peut l'intercepter. L'en-tête HSTS demande au navigateur d'utiliser exclusivement HTTPS pour votre domaine pendant une durée donnée :

Strict-Transport-Security: max-age=31536000; includeSubDomains

• max-age=31536000 : un an, exprimé en secondes ;
• includeSubDomains : la règle s'applique aussi à tous les sous-domaines.

Attention avant d'ajouter includeSubDomains : tous vos sous-domaines doivent disposer d'un certificat valide, y compris un vieil extranet ou un serveur de test oublié. Commencez par une durée courte (une journée), puis augmentez quand tout est vérifié. La directive preload permet d'inscrire le domaine dans la liste intégrée aux navigateurs, mais le retrait de cette liste prend des mois : ne l'ajoutez qu'en toute connaissance de cause. Pour les bases du chiffrement, voir mon article sur HTTPS et les certificats SSL.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Cet en-tête interdit au navigateur de « deviner » le type d'un fichier en analysant son contenu. Sans lui, un fichier envoyé par un utilisateur (une image piégée, par exemple) pourrait être interprété comme un script. C'est l'en-tête le plus simple à ajouter : une seule valeur possible, aucun effet de bord sur un serveur correctement configuré.

Protection contre l'affichage dans un cadre

Le clickjacking consiste à afficher votre site de façon invisible dans un cadre, sur une page piégée, pour faire cliquer l'utilisateur à son insu sur un bouton de votre interface. La protection moderne passe par la directive frame-ancestors de la Content Security Policy :

Content-Security-Policy: frame-ancestors 'self'

L'ancien en-tête X-Frame-Options: SAMEORIGIN reste reconnu partout et peut être conservé pour les très vieux navigateurs. La Content Security Policy fait bien plus que cela : elle mérite un article à elle seule, que vous trouverez ici : Content Security Policy.

Referrer-Policy

Quand un visiteur clique sur un lien sortant, le navigateur transmet au site de destination l'adresse de la page d'origine. Cette adresse peut contenir des informations sensibles (identifiants dans l'URL, paramètres de recherche). L'en-tête suivant limite l'information transmise à l'origine seule pour les autres sites :

Referrer-Policy: strict-origin-when-cross-origin

C'est d'ailleurs le comportement par défaut des navigateurs récents, mais le déclarer explicitement garantit un comportement identique partout.

Permissions-Policy

Cet en-tête désactive les fonctionnalités sensibles du navigateur dont votre site n'a pas besoin. Même si un script tiers est compromis, il ne pourra pas accéder à la caméra ou à la géolocalisation :

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()

Des parenthèses vides signifient « interdit à tous, y compris au site lui-même ». Si votre site utilise une de ces fonctionnalités (une carte qui localise le visiteur, par exemple), remplacez () par (self).

Configuration complète pour nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()" always;
add_header Content-Security-Policy "frame-ancestors 'self'; object-src 'none'; base-uri 'self'" always;

Deux subtilités de nginx piègent régulièrement :

• Le mot-clé always : sans lui, les en-têtes ne sont envoyés que sur les réponses réussies, pas sur les pages d'erreur ;
• L'héritage : dès qu'un bloc location contient sa propre directive add_header, il n'hérite plus d'aucune directive add_header du niveau supérieur. Un add_header Cache-Control dans la configuration des images supprime alors silencieusement tous vos en-têtes de sécurité pour ces fichiers. La solution consiste à regrouper les en-têtes dans un fichier inclus avec include dans chaque bloc concerné.

Si vous débutez avec nginx, mon guide nginx sur VPS présente l'organisation des fichiers de configuration. Sur Apache, les mêmes en-têtes s'ajoutent avec la directive Header always set du module mod_headers.

Les en-têtes à éviter ou à retirer

• X-XSS-Protection : le filtre qu'il activait a été retiré des navigateurs et pouvait lui-même créer des failles. Ne l'ajoutez plus ;
• Les en-têtes qui révèlent vos versions (Server: nginx/1.x, X-Powered-By: PHP/8.x) : sans être une faille en soi, ils facilitent le travail des robots qui recherchent des versions vulnérables. Désactivez-les avec server_tokens off; dans nginx et expose_php = Off dans PHP.

Vérifier sa configuration

L'outil MDN HTTP Observatory analyse gratuitement les en-têtes de votre site et attribue une note, avec des explications pour chaque point. En ligne de commande, curl -I https://votre-site.fr affiche les en-têtes renvoyés. Pensez à tester aussi une page d'erreur et un fichier statique, pour vérifier les deux pièges de nginx décrits plus haut.

Ces réglages prennent quelques minutes et protègent durablement vos visiteurs. Ils font partie de la configuration standard des serveurs que j'administre, au même titre que Fail2ban et la sécurisation de SSH. Si vous voulez faire vérifier votre site, je propose des audits de sécurité clairs et concrets.