En-têtes HTTP de sécurité : ce que servent vraiment 655
pages d'accueil

Le 6 octobre 2026, en quatre minutes, nous avons demandé leur page d'accueil à 704 organisations : les entreprises du SBF 120, les universités, les communes de plus de 20 000 habitants et les CHU. Une visite chacune, rien de plus. Puis nous avons lu, hors ligne, les en-têtes HTTP de sécurité que renvoyaient les 655 pages obtenues.

Un chiffre résume l'écart entre ce qui est posé et ce qui protège. 257 pages servent encore X-XSS-Protection: 1; mode=block, un en-tête que plus aucun navigateur actuel ne lit. 10 pages, sur les mêmes 655, envoient une Content Security Policy qui bloquerait réellement un script injecté. La ligne héritée d'un autre âge est plus de 25 fois plus répandue que la protection qui l'a remplacée. On reprend les en-têtes un par un : ce que les pages servent, ce que ça vaut, et le réglage qui tient.

La mesure : 704 organisations, une page chacune

Quatre panels figés avant la collecte : 119 entreprises du SBF 120 (dont dix émetteurs étrangers, d'où "entreprises du SBF 120" et pas "entreprises françaises"), 65 universités, 488 communes de plus de 20 000 habitants et 32 CHU ou CHR. Pour chacune, un seul GET vers l'adresse du site officiel, redirections suivies comme un navigateur, depuis une IP française et avec un User-Agent de robot déclaré. Aucun nouvel essai en cas d'échec, sauf pour les 12 organisations dont le port 80 ne répondait pas : un GET direct en HTTPS une demi-heure plus tard, qui a donné 8 pages. Aucun scan, aucune autre URL que la page d'accueil.

Sur 704 organisations, 655 pages ont été obtenues : 100 pour le SBF 120, 56 pour les universités, 469 pour les communes et 30 pour les CHU. Les autres ont renvoyé un refus en 403 (le plus souvent un défi anti-robot), une erreur ou un certificat refusé. Le SBF 120 est le plus touché, avec 15 refus en 403, et ses pourcentages portent donc sur 100 pages, pas 119. Tous les taux ci-dessous sont calculés sur les pages obtenues de chaque panel.

Les limites, maintenant. C'est une photo d'un jour, et la page d'accueil ne dit rien de l'espace client, de l'API ou du vieux back-office du même domaine. Un frontal peut servir des en-têtes différents à un navigateur et à notre robot. Et "présent" ne veut pas dire "efficace" : c'est même tout le sujet de cet article, et chaque fois que nous avons pu lire la valeur effective d'un en-tête, nous l'avons fait.

Les en-têtes de base sont posés, la CSP qui bloque est rarissime

Vue d'ensemble d'abord. Le graphique compare trois panels sur huit indicateurs, du plus répandu au plus rare. Les CHU, 30 pages seulement, sont repris dans le texte. Le gradient est net, et il ne dépend presque pas du panel : les en-têtes d'une ligne (nosniff, anti-clickjacking, HSTS) sont posés par une majorité de sites, les en-têtes qui demandent de connaître son application (CSP, Permissions-Policy) par une minorité, et la CSP qui bloque vraiment par presque personne.

Pour les 30 CHU et CHR obtenus : nosniff et anti-clickjacking 66,7 %, HSTS 66,7 % (50 % d'au moins un an), CSP appliquée 26,7 %, Referrer-Policy 33,3 %, Permissions-Policy valide 20 %, et une CSP stricte. Côté transport, TLS 1.3 est négocié par 94 % des pages du SBF 120 et par 86,7 à 87,5 % des autres panels : le chiffrement n'est plus le point faible, la politique au-dessus l'est.

HSTS : posé sur six pages sur dix, réglé sur un an bien moins souvent

Strict-Transport-Security, ou HSTS, est le plus utile de la liste et le plus dangereux à mal poser. Il répond à un trou précis : même un site en HTTPS partout reste vulnérable sur la première requête, quand l'utilisateur tape exemple.fr sans préfixe et que le navigateur tente d'abord le HTTP clair. Un attaquant sur le même réseau intercepte cette requête et n'a plus qu'à rester en HTTP. Une fois l'en-tête reçu, le navigateur réécrit lui-même http:// en https:// pendant toute la durée du max-age.

Dans la mesure, l'en-tête est présent sur 78 % des pages du SBF 120, 56,7 % des communes et 48,2 % des universités. La durée est l'endroit où ça se gâte : avec un max-age d'au moins un an, on tombe à 61 %, 44,8 % et 37,5 %. Un HSTS de quelques minutes ou de quelques jours est un HSTS de test resté en place : la protection s'éteint entre deux visites espacées, exactement quand l'utilisateur revient depuis le Wi-Fi d'une gare.

La valeur recommandée par le projet OWASP Secure Headers est max-age=63072000; includeSubDomains, soit deux ans, étendu à tous les sous-domaines. Le max-age est remis à zéro à chaque visite : tant que l'utilisateur revient, la protection ne s'éteint jamais. Pour un test HSTS, la ligne brute suffit :

$ curl -sI https://votre-domaine.fr | grep -i strict-transport
strict-transport-security: max-age=63072000; includeSubDomains
# max-age en secondes : 31536000 = un an, le minimum utile.
# Aucune ligne ? Pas de HSTS. Refaire le test sur chaque sous-domaine exposé.

Reste la directive preload, qui demande l'inscription du domaine sur la liste de préchargement HSTS compilée dans les navigateurs. Un domaine préchargé est forcé en HTTPS avant même la première visite. Elle figure sur 29 % des pages du SBF 120 et 31,6 % des pages de communes. La directive seule ne suffit pas : l'inscription se fait sur le site de la liste, et elle engage tous les sous-domaines.

X-XSS-Protection : 257 pages servent un en-tête que plus personne ne lit

X-XSS-Protection pilotait un filtre anti-XSS intégré aux anciens navigateurs. Ce filtre a été retiré de Chrome à la version 78 et d'Edge, et n'a jamais existé dans Firefox ; la page MDN le classe "Deprecated" et "Non-standard". OWASP recommande de ne pas l'envoyer, ou de l'envoyer à 0. Les deux réglages sont conformes, et c'est important pour lire le graphique.

Une majorité de pages fait donc ce qu'il faut, le plus souvent sans le savoir : 382 n'envoient rien. Mais 257 pages sur 655, soit 39,2 %, servent encore 1; mode=block, et seulement 14 désactivent explicitement le filtre. Par panel, la vieille valeur se trouve sur 48 pages du SBF 120 sur 100, 188 pages de communes sur 469, 14 pages d'universités sur 56 et 7 pages de CHU sur 30.

Soyons précis sur ce que ça signifie. Ce n'est pas une faille : un navigateur actuel ignore l'en-tête, donc il ne protège de rien et n'expose à rien. C'est un indice. Un serveur qui sert encore cette ligne a reçu un bloc de configuration recopié d'un tutoriel ou d'un modèle d'hébergeur, et personne ne l'a relu depuis. Le même bloc contient souvent les autres réglages de l'époque, ce qui se vérifie sur Referrer-Policy un peu plus bas. Et un scanner d'en-têtes qui pénalise encore l'absence de X-XSS-Protection vous pousse vers ce bloc. La protection contre le XSS passe par la CSP.

CSP : 10 pages sur 655 bloqueraient un script injecté

La Content-Security-Policy déclare au navigateur quelles sources de scripts, de styles, d'images ou de trames sont autorisées. Une politique stricte sur les scripts interdit tout script inline ou distant non prévu : un XSS injecté dans la page ne s'exécute plus, même si l'attaquant a réussi à écrire son <script> dans le HTML.

Une CSP appliquée par en-tête apparaît sur 58 % des pages du SBF 120, 29,4 % des communes, 26,7 % des CHU et 25 % des universités. Mais la plupart sont des CSP de façade. Sur les 58 du SBF 120, 31 gardent 'unsafe-inline' effectif sur les scripts, qui autorise précisément ce qu'un XSS injecte, et 20 n'ont aucune directive qui concerne les scripts. Côté communes, 76 pages ont un 'unsafe-inline' effectif et 67 un joker (*, https:) sur les scripts.

En retenant la règle stricte (CSP appliquée, ni 'unsafe-inline' effectif ni joker sur les scripts, 'unsafe-eval' toléré), il en reste 10 sur 655 pages : 7 au SBF 120, 2 dans les communes, 1 dans un CHU, aucune dans les universités. Deux de ces sept pages du SBF 120 tolèrent en plus 'unsafe-eval'. Le piège du report-only existe aussi dans la mesure : 3 pages du SBF 120 et 7 pages de communes n'envoyaient qu'une Content-Security-Policy-Report-Only, qui signale les violations sans rien bloquer.

Et selon le CMS ?

La question vient naturellement, et la réponse honnête est qu'on ne peut pas trancher. Ventilées par CMS détecté sur les 636 pages à contenu exploitable, les CSP strictes se comptent sur les doigts : 1 sur 272 pages WordPress, 2 sur 136 pages Drupal, 0 sur 77 pages TYPO3, 1 sur 47 pages d'un autre CMS et 6 sur 104 pages où aucun CMS n'a été identifié. Avec des effectifs de 0 à 6, aucun classement entre CMS ne tient. Ce que ces chiffres disent, c'est que la CSP stricte est rare partout. Sur WordPress, le compromis entre thème, extensions et scripts inline est détaillé dans notre guide pour sécuriser un site WordPress.

La sortie propre existe depuis longtemps : le nonce et le hash. Plutôt qu''unsafe-inline', on déclare script-src 'nonce-XyZ...' et on répète ce jeton aléatoire, régénéré à chaque réponse, sur chaque balise <script> légitime. Un script injecté ne connaît pas le nonce, donc ne tourne pas. La variante 'sha256-...' autorise un bloc inline figé par son empreinte. On commence en report-only pour recenser ce qui casserait, puis on bascule en mode bloquant, et c'est cette bascule qu'il ne faut pas oublier.

# Point de départ raisonnable, à roder d'abord en Content-Security-Policy-Report-Only
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{aleatoire}';
  object-src 'none'; base-uri 'none'; frame-ancestors 'none'

Referrer-Policy et Permissions-Policy : présentes ne veut pas dire efficaces

Referrer-Policy contrôle ce que votre site divulgue dans l'en-tête Referer quand un visiteur suit un lien ou charge une ressource tierce. Le piège, c'est que le défaut des navigateurs actuels, quand l'en-tête est absent, est déjà raisonnable : strict-origin-when-cross-origin, qui n'envoie que l'origine vers l'extérieur. Poser l'en-tête avec une valeur plus laxiste dégrade donc la situation.

Referrer-Policy est présente sur 257 pages sur 655 (39,2 %). Mais 108 d'entre elles, soit 42 %, la fixent à no-referrer-when-downgrade (75) ou à unsafe-url (33) : l'URL complète, chemin et paramètres compris, part vers les sites tiers. Ces pages seraient mieux protégées sans l'en-tête. L'écart est très inégal : 95 des 184 pages de communes qui envoient l'en-tête sont dans ce cas, contre 8 sur 48 au SBF 120. no-referrer-when-downgrade était le défaut des navigateurs il y a quelques années : c'est, à nouveau, la signature d'un bloc de configuration d'époque.

Permissions-Policy désactive les API sensibles du navigateur que votre site n'utilise pas (caméra, micro, géolocalisation), ce qui réduit d'autant ce qu'un script injecté pourrait solliciter. 155 pages l'envoient, 150 avec une syntaxe valide (22,9 % des 655). Les 5 autres écrivent la valeur dans l'ancienne syntaxe Feature-Policy, avec 'self' entre apostrophes, que le navigateur ignore. L'ancien en-tête Feature-Policy lui-même est encore servi par 11 pages, et Expect-CT, abandonné par les navigateurs, par 24.

Anti-clickjacking et nosniff : les deux lignes qu'on oublie le moins

Les deux en-têtes les plus répandus sont aussi les plus simples. X-Content-Type-Options: nosniff interdit au navigateur de deviner le type d'un fichier au lieu de croire le Content-Type : sans lui, un fichier téléversé et servi en text/plain peut être réinterprété en HTML exécutable. Il est posé par 81 % des pages du SBF 120 et 62 à 67 % des autres panels.

Contre le clickjacking (superposer votre page sous un leurre pour détourner les clics), on compte ensemble X-Frame-Options à DENY ou SAMEORIGIN et la directive CSP frame-ancestors : 79 % au SBF 120, 66,7 % dans les CHU, 64,3 % dans les universités et 53,1 % dans les communes. frame-ancestors est le signal moderne, qui prime sur l'ancien en-tête dans les navigateurs actuels ; on garde souvent les deux par prudence.

Le bon réglage, en-tête par en-tête

Ce qu'une page d'accueil ne dit pas

Notre mesure a la même limite qu'un scanner d'en-têtes : une URL par organisation. C'est sa limite structurelle. À côté du site vitrine vivent un espace client sur un sous-domaine, une API sur un autre, un vieux back-office qui ne renvoie aucun de ces en-têtes. Le durcissement HTTP est une propriété de chaque hôte exposé, pas du domaine principal, et une page d'accueil correcte ne dit rien des services voisins.

C'est le champ de la gestion de la surface d'attaque externe (EASM). Avant de vérifier des en-têtes, il faut savoir sur quoi les vérifier, et la découverte des actifs exposés remonte régulièrement des hôtes perdus de vue. Une fois la cartographie faite, le contrôle des en-têtes devient une ligne parmi d'autres dans une gestion des vulnérabilités continue. C'est aussi la différence entre un scanner d'en-têtes gratuit et un scanner de vulnérabilité appliqué à tout un périmètre : le premier note une page, le second dit quels hôtes, parmi tous ceux que vous exposez, laissent la porte ouverte. La surveillance de surface d'attaque own2pwn relève les en-têtes manquants ou incohérents sur l'ensemble des services découverts.

À retenir

• La présence ne vaut pas protection. Sur 655 pages d'accueil, 257 envoient Referrer-Policy mais 108 avec une valeur plus laxiste que le défaut du navigateur, et seules 10 ont une CSP qui bloquerait un script injecté.
• HSTS est posé par six pages sur dix (391 sur 655), mais la durée d'au moins un an manque souvent. Valeur solide : max-age=63072000; includeSubDomains, et le preload seulement sur un arbre 100 % HTTPS.
• X-XSS-Protection est ignoré par les navigateurs actuels. L'absence ou la valeur 0 sont conformes. Les 257 pages en 1; mode=block ne sont pas vulnérables pour autant : elles signalent une configuration jamais relue.
• La CSP est le vrai rempart anti-XSS, à condition de bannir 'unsafe-inline' et les jokers sur les scripts, et de ne pas oublier la bascule du report-only vers le mode bloquant.
• Une page n'est pas un périmètre. Le durcissement se vérifie hôte par hôte, ce qui suppose un inventaire complet.

Poser sept en-têtes sur sa page d'accueil prend dix minutes, relire ceux qui y sont déjà en prend cinq et évite de traîner un bloc d'une autre époque. Savoir qu'ils sont posés, et bien posés, sur chacun des services exposés sur Internet, c'est un travail d'inventaire continu. Si vous ne savez pas combien d'hôtes portent votre nom de domaine, commencez par les cartographier avant de les noter. Et si vous voulez qu'un humain regarde ce que les en-têtes laissent passer sur une application précise, parlez-nous de votre périmètre.

Questions fréquentes sur les en-têtes HTTP de sécurité