En-têtes de sécurité HTTP : guide complet de CSP, HSTS et des autres

L’essentiel de la sécurité d’un site vit dans son code, mais un petit ensemble d’en-têtes de réponse HTTP décide de ce que le navigateur acceptera de faire avec ce code une fois reçu. Ils font la différence entre un <script> injecté qui s’exécute et un que le navigateur refuse d’exécuter, entre une première visite en HTTP non chiffré et une visite basculée en HTTPS avant même de quitter la barre d’adresse.

Ils sont aussi exceptionnellement peu coûteux à déployer. Un en-tête est de la configuration, pas du code : la plupart tiennent en une ligne dans votre serveur web, votre CDN ou votre framework, et s’appliquent d’un coup à toutes les réponses. Ce guide couvre le rôle de chaque en-tête, lesquels sont rentables, comment déployer une Content-Security-Policy sans casser votre propre site, et comment vérifier ce que vous envoyez aujourd’hui.

Pourquoi les en-têtes de sécurité comptent

Un en-tête est une instruction au navigateur, et le navigateur est le seul acteur capable de l’appliquer sur la machine de l’utilisateur. Cela en fait une seconde ligne de défense qui tient même lorsque quelque chose en amont a déjà échoué :

• Ils contiennent les erreurs déjà commises. Une Content-Security-Policy ne corrige pas une faille XSS, mais elle peut empêcher le script injecté de s’exécuter ou de renvoyer quoi que ce soit.
• Ils ferment des classes entières d’attaques. Le clickjacking, la confusion de type MIME et le retour en HTTP ne sont pas des bogues de votre code : ce sont des comportements du navigateur dont il faut explicitement se retirer.
• Ils stoppent les fuites discrètes de données. Sans politique de référent, l’URL complète d’une page privée voyage vers chaque tiers dont vous chargez une image.
• C’est la première chose qu’un auditeur regarde. Les en-têtes manquants apparaissent dans chaque scan automatique, questionnaire de sécurité et revue fournisseur, parce que c’est le constat le moins coûteux à faire.

Le piège, c’est qu’il est facile de les rendre presque corrects. Une CSP avec unsafe-inline ne bloque presque rien ; un en-tête HSTS d’une durée d’un jour ne protège quasiment personne. Toute la valeur est dans les détails.

Les en-têtes qui comptent le plus

Six en-têtes font presque tout le travail utile. Les autres sont hérités, de portée très étroite, ou dépassés.

Commencez par le bas. Les quatre en-têtes bon marché tiennent en une ligne chacun et ne cassent presque jamais rien : ils méritent d’être livrés aujourd’hui. La CSP est celle qui demande un plan.

Content-Security-Policy

La CSP est une liste d’autorisations qui indique au navigateur d’où chaque type de ressource peut venir. Une politique raisonnablement stricte ressemble à ceci :

default-src 'self'; script-src 'self' 'nonce-r4nd0m'; style-src 'self'; img-src 'self' data:; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; object-src 'none'

Lisez-la directive par directive. default-src 'self' est le repli : tout ce qui n’est pas nommé explicitement ne peut charger que depuis votre propre origine. script-src est la plus importante, car ce sont les scripts qu’un attaquant veut exécuter. frame-ancestors 'none' interdit à tout autre site de placer votre page dans une iframe : c’est le remplaçant moderne de X-Frame-Options. object-src 'none' et base-uri 'self' ferment deux vieux contournements qu’il ne coûte rien de condamner.

Deux valeurs décident si votre politique est réelle. 'unsafe-inline' dans script-src autorise n’importe quel <script> en ligne, y compris celui qu’un attaquant a injecté, c’est-à-dire précisément ce que la CSP est censée empêcher. 'unsafe-eval' autorise eval() et ses proches. Une politique contenant l’un ou l’autre reste utile pour les directives hors script, mais elle ne vous protège pas du XSS.

La sortie, c’est un nonce ou un hash. Un nonce est une valeur aléatoire générée par réponse et attachée à la fois à l’en-tête et à chaque <script nonce="..."> légitime ; le navigateur n’exécute que les scripts portant cette valeur, qu’un script injecté ne peut pas deviner. Les hash fonctionnent de même pour des scripts qui ne changent jamais. Si votre framework rend des scripts en ligne, il gère presque certainement déjà les nonces : il suffit souvent d’activer une option.

Strict-Transport-Security

HSTS demande au navigateur de refuser le HTTP non chiffré pour votre domaine pendant une durée donnée, ce qui ferme la brèche qu’une simple redirection laisse ouverte : la toute première requête, avant l’arrivée de la redirection, voyage en clair et peut être interceptée.

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

Le max-age est en secondes ; un an est la cible habituelle, et en dessous de quelques mois l’apport est faible. includeSubDomains étend la règle à tous les sous-domaines, ce qui la rend efficace et mérite d’être vérifié d’abord : tout sous-domaine encore servi en HTTP cessera de fonctionner. preload demande l’inscription dans la liste livrée avec les navigateurs, pour que même la première visite soit protégée.

Traitez HSTS comme difficile à annuler. Un navigateur ayant vu une politique d’un an l’appliquera un an, quoi que vous envoyiez ensuite. Déployez-la avec un max-age court, vérifiez que rien n’a cassé, puis augmentez-le. Et comme HSTS n’a d’intérêt que si le certificat derrière est valide, vérifiez le certificat et son expiration avec le vérificateur de certificats SSL avant de vous engager sur une longue durée.

Les petits en-têtes

Ces quatre-là tiennent en une ligne chacun et sont rarement sujets à débat :

• X-Content-Type-Options: nosniff — empêche le navigateur de deviner le type d’une réponse d’après son contenu. Sans lui, un fichier déposé en .txt peut être exécuté comme script si le navigateur décide qu’il y ressemble.
• Referrer-Policy: strict-origin-when-cross-origin — envoie l’URL complète à votre propre origine, seulement l’origine aux autres sites HTTPS, et rien lors d’un passage en HTTP. C’est le défaut moderne, et il empêche les chemins et paramètres privés de fuir vers des tiers.
• Permissions-Policy: camera=(), microphone=(), geolocation=() — désactive les fonctions matérielles que votre site n’utilise pas, pour votre page comme pour ce que vous intégrez.
• Cross-Origin-Opener-Policy: same-origin — coupe le lien de fenêtre avec les pages que vous ouvrez ou qui vous ouvrent, ce qui bloque une famille d’attaques inter-fenêtres et conditionne certaines fonctions d’isolation du navigateur.

X-Frame-Options: DENY a encore sa place pour les navigateurs anciens, mais frame-ancestors dans votre CSP le remplace et est plus expressif. Envoyez les deux : ils n’entrent pas en conflit.

Déployer une CSP sans risque

Une CSP écrite au hasard bloquera quelque chose dont votre propre site a besoin. La voie du « rapport d’abord » évite cela entièrement :

1. Livrez aujourd’hui les quatre en-têtes bon marché. nosniff, une politique de référent, une politique de permissions et HSTS avec un max-age court. Aucun ne casse normalement un site qui fonctionne.
2. Ajoutez Content-Security-Policy-Report-Only. Syntaxe identique, mais le navigateur signale les violations au lieu de les bloquer. Votre site se comporte exactement comme avant.
3. Collectez les rapports une à deux semaines. Ils nommeront chaque script tiers, police, point d’analytique et gestionnaire en ligne que vous aviez oublié. C’est l’étape que l’on saute, et c’est elle qui rend la suite indolore.
4. Resserrez jusqu’au silence des rapports. Ajoutez les sources dont vous avez réellement besoin et retirez celles dont vous découvrez que non. Résistez à l’envie d’élargir une directive à * pour faire taire un seul rapport.
5. Passez en mode appliqué. Renommez l’en-tête en Content-Security-Policy. Gardez la version report-only à côté pour tester plus tard une politique plus stricte.
6. Retirez unsafe-inline en dernier. C’est le vrai travail : déplacer les scripts en ligne vers des fichiers ou leur donner des nonces. Tout ce qui précède n’est que préparation ; c’est cette étape qui arrête le XSS.

Une remarque pratique : les en-têtes sont par réponse, donc posez-les en périphérie — CDN, proxy inverse ou middleware du framework — et non page par page. Le faire en un seul endroit est aussi le seul moyen d’être sûr que vos pages d’erreur et vos redirections les portent aussi, et c’est précisément là qu’ils manquent d’habitude.

Les en-têtes que vous pouvez arrêter d’envoyer

Certains conseils ont mal vieilli, et envoyer un en-tête mort n’est pas sans conséquence : cela ajoute des octets et fait paraître un audit terminé alors qu’il ne l’est pas.

• X-XSS-Protection — les filtres du navigateur qu’il pilotait ont disparu. Il ne fait rien dans aucun navigateur actuel, et l’ancienne valeur mode=block a même introduit ses propres problèmes. Retirez-le et appuyez-vous sur la CSP.
• Public-Key-Pins — HPKP a été retiré des navigateurs. Il était facile de se verrouiller hors de son propre domaine, d’où son abandon.
• Expect-CT — la transparence des certificats est désormais appliquée par défaut, l’en-tête est donc redondant.
• Feature-Policy — renommé Permissions-Policy, avec une autre syntaxe. Envoyez le nouveau ; ne gardez l’ancien que si vous devez supporter quelque chose de très vieux.

À l’inverse, une chose mérite d’être retirée : l’information que vous offrez. Un en-tête Server ou X-Powered-By nommant la version exacte de votre framework indique à un attaquant quels exploits essayer en premier. Ce n’est pas une vulnérabilité, mais il n’y a aucune raison de le publier.

Comment vérifier vos propres en-têtes

Les en-têtes sont publics : vérifier la configuration d’un site prend quelques secondes.

1. curl -I https://example.com. Une requête HEAD affiche tous les en-têtes de réponse sans télécharger la page. Ajoutez -L pour inspecter l’URL finale plutôt qu’une redirection.
2. Le panneau réseau du navigateur. Ouvrez les outils de développement, rechargez, sélectionnez le document principal et lisez la section des en-têtes de réponse. La console journalise aussi chaque violation de CSP avec la directive qui a bloqué, ce qui est le moyen le plus rapide de déboguer une politique.
3. Un vérificateur qui note le résultat. Notre vérificateur d’en-têtes de sécurité interroge une URL et indique quels en-têtes sont présents, lesquels manquent, et où un en-tête présent est plus faible qu’il n’y paraît.

Ne vérifiez pas seulement votre page d’accueil. Les en-têtes sont souvent posés sur l’application principale mais pas sur les hôtes de ressources statiques, les pages d’erreur, les sous-domaines d’API ou la redirection qui mène de www au domaine racine. Pendant que vous y êtes, vérifiez que la chaîne de redirection elle-même est correcte ; la référence des codes de statut HTTP précise quel code convient à un déplacement définitif.

Pour écrire une politique sans apprendre la syntaxe, partez de notre générateur CSP, qui signale aussi les réglages qui l’affaiblissent.

Erreurs courantes à éviter

• Une CSP avec unsafe-inline dans script-src. Elle passe la plupart des contrôles automatiques et n’arrête presque aucun XSS. Utilisez un nonce ou des hash.
• Élargir une directive à * pour corriger un rapport. Ajoutez plutôt l’origine précise ; * abandonne complètement la directive.
• HSTS avec un max-age long dès le premier jour. C’est de fait irréversible pour la durée publiée. Commencez court.
• includeSubDomains avant d’auditer les sous-domaines. Tout ce qui reste en HTTP, outils internes compris, cesse de charger.
• Des en-têtes sur l’application mais pas en périphérie. Les pages d’erreur, les redirections et les hôtes de ressources finissent non protégés, et ce sont justement les réponses que visent les attaquants.
• Envoyer deux fois le même en-tête. Deux en-têtes CSP sont intersectés, pas fusionnés : le résultat est plus strict que chacun et casse souvent quelque chose ; deux valeurs contradictoires de X-Frame-Options peuvent être entièrement ignorées.
• Continuer à livrer X-XSS-Protection et s’en satisfaire. Un en-tête mort donne une fausse assurance dans un rapport.
• Ne jamais dépasser le mode report-only. Des rapports sur lesquels on n’agit pas ne protègent personne.

Vérifiez vos en-têtes

Les en-têtes de sécurité offrent le meilleur rapport protection/effort du web : quatre d’entre eux tiennent en une ligne, et le cinquième, la CSP, consiste surtout à écouter vos propres rapports de violation avant d’appliquer quoi que ce soit. Commencez par regarder ce que votre site envoie aujourd’hui, ajoutez immédiatement les en-têtes bon marché, puis mettez en place une CSP en report-only et laissez-la vous dire ce que votre politique doit contenir.

Outils et guides associés :

• Vérificateur d’en-têtes de sécurité : voyez quels en-têtes une URL envoie et lesquels manquent.
• Vérificateur de certificats SSL : contrôlez le certificat derrière votre politique HSTS.
• Codes de statut HTTP : assurez-vous que votre redirection HTTPS renvoie le bon code.
• Recherche DNS : guide complet : les enregistrements derrière chaque nom d’hôte de votre politique.

Questions fréquentes