Les en-têtes de sécurité, expliqués
Un en-tête de sécurité est une seule ligne dans une réponse HTTP qui change ce que le navigateur du visiteur peut faire de votre page : exécuter des scripts uniquement depuis des sources nommées, ne plus jamais parler en HTTP clair, refuser d’être encadrée, refuser de deviner les types de contenu. Aucun n’a besoin de code, d’une bibliothèque ou d’un redémarrage — et pourtant la plupart des sites web en envoient peu ou aucun, et c’est pourquoi la plupart obtiennent F quand un scanner les vérifie. Cet article passe en revue, en-tête par en-tête, ce que chacun arrête réellement, explique l’épidémie de F et donne l’ordre de correction qui récupère le plus de protection par heure de travail. Pour voir le verdict de votre propre site, lancez d’abord l’analyse des en-têtes de sécurité et lisez avec vos résultats ouverts.
Les en-têtes sont des instructions pour le navigateur, pas une armure de serveur
Commencez par ce qu’un en-tête n’est pas. Un en-tête de sécurité ne corrige pas votre application, ne filtre pas votre trafic et n’authentifie personne. C’est une déclaration que le serveur attache à une réponse, et le navigateur — le navigateur du visiteur, sur la machine du visiteur — l’applique à partir de ce moment. Cela semble faible jusqu’à ce que l’on remarque combien d’attaques sont exécutées par le navigateur au nom de l’attaquant : lancer un script que quelqu’un a injecté dans un champ de commentaire, charger votre page de connexion dans un cadre invisible sur un site hostile, traiter un fichier texte téléversé comme du HTML parce que son contenu ressemblait à un script. Les en-têtes sont la manière dont le serveur dit au navigateur, à l’avance, lesquels de ces mouvements ne sont jamais légitimes sur ce site.
Ce sont aussi de la défense en profondeur, et ils doivent se lire ainsi. Les références canoniques de cet espace sont la documentation HTTP de MDN, qui spécifie la syntaxe et la sémantique de chaque en-tête, et le projet d’en-têtes sécurisés d’OWASP, dont les valeurs recommandées sont désignées par le guide de test du guide de test de sécurité web d’OWASP. Aucune des deux sources ne promet que les en-têtes rendent un site sûr. Elles promettent quelque chose de plus étroit et de vrai : avec les en-têtes en place, des classes entières d’attaques exécutées par le navigateur cessent de fonctionner, même quand un bogue applicatif donne une prise à l’attaquant.
Ce que chaque en-tête arrête réellement
Content-Security-Policy empêche les scripts injectés de s’exécuter. Le XSS et ses cousins — un commentaire stocké porteur d’un script, un script de skimming injecté via une balise tierce compromise — ont tous besoin que le navigateur exécute du code que le site n’a jamais voulu. Une CSP est une liste d’autorisations : script-src nomme les origines d’où les scripts peuvent venir, et tout le reste, y compris les scripts en ligne et tout ce qui est chargé depuis le serveur d’un attaquant, est refusé. Ses formes faibles sont célèbres : une politique contenant 'unsafe-inline' laisse tourner tous les scripts en ligne, y compris l’injecté, et c’est pourquoi l’outil traite une telle politique comme faible plutôt que bonne. CSP est l’en-tête le plus lourd à déployer et celui qui arrête le plus.
Strict-Transport-Security arrête la dégradation. La première fois qu’un visiteur tape votre domaine sans schéma, ou suit un vieux lien http://, cette requête traverse le réseau en clair, où elle peut être dépouillée, redirigée ou lue — cookie de session inclus. HSTS dit au navigateur : pendant les prochaines max-age secondes, réécris chaque URL http:// de cet hôte en https:// avant que quoi que ce soit ne quitte la machine, et refuse les clics qui ignorent les erreurs de certificat. Une limite honnête : HSTS ne protège que les visiteurs dont les navigateurs ont déjà vu l’en-tête une fois (les listes de préchargement intégrées aux navigateurs existent pour fermer exactement cette brèche de première visite), et il n’est honoré que lorsqu’il arrive lui-même en HTTPS.
La protection contre les cadres arrête le clickjacking. Si vos pages peuvent être intégrées dans un cadre, un site hostile peut tendre votre vraie interface sous une couche transparente de ses propres boutons et récolter les clics : la victime voit une page inoffensive et approuve un virement. La directive CSP frame-ancestors (et sa sœur aînée, X-Frame-Options: DENY ou SAMEORIGIN) nomme qui peut vous encadrer ; tous les autres reçoivent un cadre vide. X-Content-Type-Options: nosniff arrête un tour plus discret : les navigateurs devinaient historiquement le Content-Type déclaré et exécutaient des fichiers comme des scripts ou du HTML quand le contenu y ressemblait, transformant un téléversement innocent en XSS stocké. nosniff met fin aux devinettes — le type déclaré est le type.
Referrer-Policy arrête la fuite d’URL. Quand un visiteur clique depuis votre page vers un autre site, le navigateur envoyait historiquement l’URL complète de votre page comme Referer — y compris les jetons de réinitialisation de mot de passe, termes de recherche ou identifiants d’enregistrements qui s’y trouvaient. Une politique strict-origin-when-cross-origin ou plus stricte n’envoie que l’origine entre sites et rien aux cibles http sujettes à la dégradation. Permissions-Policy arrête l’abus de fonctionnalités : elle déclare quelles capacités puissantes du navigateur — appareil photo, microphone, géolocalisation, gestionnaires de paiement — ce site peut utiliser tout court, pour qu’un cadre ou un script injecté ne puisse pas les demander en silence en votre nom. Et l’en-tête bonus, Cross-Origin-Opener-Policy, coupe le lien window.opener entre votre page et les fenêtres surgissantes d’autres origines, isolant votre contexte de navigation des pages qui pourraient le sonder.
Pourquoi tant de sites obtiennent F
Parce que la configuration par défaut de personne n’envoie ces en-têtes. Un serveur web d’origine, un échafaudage de framework d’origine, un hébergement statique d’origine : chacun envoie des réponses avec au plus un ou deux des six, et les deux plus précieux — CSP et Permissions-Policy — exigent des décisions propres au site, si bien qu’aucune configuration par défaut ne peut les envoyer en sécurité. La responsabilité se divise alors en trois : l’équipe du framework suppose que le serveur ajoute les en-têtes, l’équipe du serveur suppose que le framework le fait, et le CDN devant réécrit de toute façon ce qui lui plaît. Les en-têtes tombent dans la fissure, en silence, parce que sans eux rien ne casse visiblement. Un site noté F ressemble et fonctionne en général exactement comme un site noté A ; la différence n’apparaît que le jour où une attaque a besoin de la coopération du navigateur.
Les chiffres publiés concordent avec cette histoire. L’échantillon publié d’un scanner, rapporté dans la revue hebdomadaire d’outils du 2026-11-04, a trouvé 65 % des sites scannés notés F et 51 % n’envoyant aucune Content-Security-Policy. Traitez-les pour ce qu’ils sont — l’échantillon d’un scanner, publié par un tiers, pas une mesure de tout le web et pas nos propres données —, mais la direction est corroborée par l’expérience de chaque opérateur : les en-têtes sont ce rare contrôle de sécurité dont l’absence est la norme statistique. Et c’est aussi la bonne nouvelle cachée dans la statistique : la barre est au sol, et la franchir relève de la configuration, pas de l’ingénierie.
Ordre de correction, par impact par heure
Travaillez dans l’ordre que l’analyse des en-têtes de sécurité rend évident. D’abord, les lignes uniques : X-Content-Type-Options: nosniff, la protection contre les cadres et une Referrer-Policy sensée — trente-cinq des cent points, quelques minutes de travail et un risque de casse pratiquement nul sur un site normal. Ensuite, HSTS — vingt points de plus —, mais seulement après avoir vérifié que chaque page, sous-domaine et redirection héritée fonctionne vraiment en HTTPS, car un long max-age ne peut pas être désenvoyé. Troisièmement, Permissions-Policy : listez les fonctionnalités que votre site utilise vraiment, désactivez le reste ; dix points pour une ligne soignée.
En dernier, et lentement, CSP. Ses 35 points forment le plus gros bloc individuel et le seul correctif qui puisse mettre votre propre site à terre. Déployez-la d’abord comme Content-Security-Policy-Report-Only avec un point de terminaison de rapports, lisez une semaine de violations, réécrivez les scripts en ligne et les gestionnaires d’événements qu’elle signale — ou adoptez des nonces, comme le recommande le guide MDN — et ne passez à l’application forcée que lorsque les rapports se taisent. Ajoutez Cross-Origin-Opener-Policy: same-origin chaque fois que vous ne dépendez pas de flux de fenêtres surgissantes inter-origines ; il n’est pas noté dans notre tableau, mais c’est un isolement bon marché. Relancez ensuite l’analyse et confirmez que les en-têtes ajoutés à l’origine ont vraiment survécu au CDN et aux proxies devant eux.
Ce que les en-têtes ne peuvent pas faire
Ils ne peuvent pas réparer le trou, seulement réduire ce qu’un attaquant peut faire à travers lui. Une CSP ne répare pas le champ de commentaire qui n’a pas échappé son entrée ; elle fait que la charge injectée refuse de tourner. HSTS ne répare pas une chaîne de certificats cassée — c’est le territoire de l’évaluateur SSL — et aucun en-tête ne remplace les correctifs, les sauvegardes ou le contrôle d’accès. Lisez une note parfaite en en-têtes comme une porte bien verrouillée sur un bâtiment dont les autres étages ont encore besoin de leurs propres vérifications, ce à quoi sert le bilan de santé du site.
Ils ne peuvent pas non plus être posés puis oubliés. Une CSP écrite pour le site de l’an dernier bloque en silence le widget de paiement de cette année — ou, pire, se relâche avec un * à la hâte et ne signifie plus rien. Traitez l’ensemble d’en-têtes comme le reste de votre configuration : versionné, revu quand le site change, et revérifié après chaque changement de plateforme. La vérification prend dix secondes ; lancez-la chaque fois que la pile devant vos pages change, et l’épidémie de F restera la statistique de quelqu’un d’autre.