Les en-têtes de sécurité que la plupart des sites ignorent encore : données provenant de 49 audits réels

Pour ce rapport, nous avons lu 6 en-têtes de sécurité dans la réponse finale de la page d’accueil de chaque site audité, après redirections. Un en-tête envoyé uniquement sur un saut pré-redirection ne compte pas, car le navigateur ne l’applique jamais à la page. La question est délibérément étroite : l’en-tête était-il présent dans la réponse du tout.

Sur 49 sites audités entre mai 23 et August 31, 2026, la réponse est généralement non. Permissions-Policy est manquant sur 69% d’entre eux, Referrer-Policy sur 65%, Content-Security-Policy sur 61%, X-Frame-Options sur 51%, X-Content-Type-Options sur 43%, et Strict-Transport-Security — le meilleur adopté parmi les 6 — sur 41%.

Méthodologie : dernier instantané d’audit terminé par domaine à partir de notre jeu de vérification actuel, approximativement mai 23 – August 31, 2026, 49 domaines distincts, anonymisés. Chaque pourcentage représente la part de sites dont la réponse de la page d’accueil ne portait pas cet en-tête. L’échantillon est auto-sélectionné — propriétaires ayant effectué un audit — et penche vers les petits et moyens sites, ce qui sous-estime probablement l’adoption des en-têtes sur l’ensemble du web, puisque les grandes plateformes les définissent à la périphérie. Considérez les parts comme indicatives pour la longue traîne.

Ces chiffres comptent la présence, pas la qualité

La précision de la mesure est importante ici, car elle fixe le plafond de ce que ces chiffres peuvent affirmer.

Les chiffres décrivent 1 réponse par site : la page d’accueil, après redirections. La présence signifie une valeur non vide, et rien de plus. Un en-tête Strict-Transport-Security dont le max-age est 1 seconde compte comme présent, tout comme un Content-Security-Policy suffisamment permissif pour tout autoriser. La présence ne dit rien sur la qualité de construction de la politique.

Cela ressemble à un bar faible jusqu’à ce que l’on considère ce qu’il mesure. Un en-tête avec n’importe quelle valeur est la preuve qu’un humain a une fois ouvert une configuration serveur, une règle CDN, ou un fichier middleware et a tapé une directive. La mesure est un test de savoir si la couche de configuration d’un site a déjà été touchée intentionnellement — c’est pourquoi les taux d’échec sont la partie intéressante, pas les taux de réussite.

Deux détails déterminent si un en-tête que vous envoyez déjà protège réellement quelque chose :

• Le CSP en mode report-only n’applique rien. Content-Security-Policy-Report-Only enregistre les violations sans les bloquer. C’est la bonne façon de commencer, mais tant que l’en-tête Content-Security-Policy qui applique la politique n’est pas déployé, celle-ci ne protège rien.
• frame-ancestors et X-Frame-Options atteignent des clients différents. Une directive CSP frame-ancestors est le meilleur contrôle, et les anciens clients ne lisent que l’en-tête hérité X-Frame-Options. Déployez les deux.

L'adoption suit l'âge d'un en-tête, pas sa difficulté

L'ordre des taux d'échec est proche d'un ordre chronologique inversé. HSTS, le plus ancien des 6 et réduisible à un interrupteur dans chaque tableau de bord CDN majeur, est le plus adopté. X-Content-Type-Options et X-Frame-Options, deux conventions de fournisseurs bien antérieures à leurs successeurs formels, se situent au milieu. Referrer-Policy et Permissions-Policy, les deux plus récents, sont les deux plus manquants — et Permissions-Policy, que aucun hôte commun ne définit en votre nom, est le dernier.

Aucun d'eux n'est plus difficile que les autres en termes d'ingénierie. 5 des 6 sont une seule ligne statique dans un bloc serveur, une règle CDN, ou un fichier middleware edge, sans changements d'application et sans risque comportemental. Ce qui les sépare, c'est le temps qu'ils ont eu pour accumuler des valeurs par défaut et le nombre de billets de blog, de listes de vérification et de modèles de framework qui les ont absorbés. Nous avons vu la même forme lorsque nous avons classé chaque vérification échouée à travers notre historique d'audit : les en-têtes de réponse dominaient le sommet de la liste, au-dessus de la canonisation, du rendu et de la performance. Ce classement couvrait une fenêtre différente, un échantillon différent et un ensemble de vérifications antérieur, donc les deux ensembles de pourcentages ne constituent pas une ligne de tendance — mais la position des en-têtes en haut des deux est la constatation durable.

La raison structurelle supplémentaire est l'invisibilité. Un en-tête manquant ne change rien à l'écran. Aucun CMS ne vous avertit, aucune construction ne plante, aucun tableau de bord ne devient rouge. L'absence n'est observable que par quelque chose qui inspecte les réponses brutes — ce qui est exactement ce qu'un audit, l'état de sécurité d'un navigateur et une part croissante de lecteurs automatisés font. C'est la même asymétrie que nous avons trouvée dans render parity : ce que les humains voient dans un navigateur et ce que les machines reçoivent sur HTTP se sont discrètement divergés.

Ce que chaque en-tête protège

Strict-Transport-Security indique au navigateur de refuser le HTTP en texte clair pour votre domaine pendant une période indiquée, ce qui ferme la fenêtre de redirection qu'un attaquant sur le réseau peut hijacker avant que votre redirection http:// → https:// ne se déclenche. C’est également le seul en-tête de la liste qui comporte un engagement : les navigateurs honorent le max-age même si vous rompez plus tard le HTTPS. Commencez court, confirmez que chaque sous-domaine et chaque ressource sont servis proprement via TLS, puis étendez.

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

Content-Security-Policy limite d’où les scripts, styles, cadres et connexions peuvent provenir. C’est le seul en-tête ici qui contient un incident plutôt que de prévenir une catégorie d’un type : lorsqu’un gestionnaire de balises est compromis ou que l’entrée utilisateur atteint le DOM, CSP décide si le script injecté peut s’exécuter ou atteindre un serveur qu’il choisit. C’est aussi le seul qui peut casser une page fonctionnelle, c’est pourquoi il appartient à la fin de la séquence ci-dessous.

Content-Security-Policy-Report-Only: default-src 'self'

X-Frame-Options déclare si d’autres origines peuvent placer vos pages dans un cadre. Sans lui, votre interface peut être intégrée sous une superposition transparente sur la page d’un attaquant et cliquée par des utilisateurs qui pensent être sur votre site. Le CSP moderne exprime cela mieux avec frame-ancestors; expédiez les deux, car les anciens clients ne lisent que l’en-tête hérité.

X-Frame-Options: DENY

X-Content-Type-Options empêche les navigateurs de deviner le type d’une réponse lorsque le Content-Type déclaré semble incorrect. Le sniffing est la façon dont un fichier téléchargé que vous servez en texte peut être exécuté comme un script à la place. L’en-tête a exactement 1 valeur valide.

X-Content-Type-Options: nosniff

Referrer-Policy régit la quantité de l’URL actuel qui voyage vers des tiers lors des clics sortants et des chargements de sous‑ressources. Vos URLs portent des paramètres de campagne, des requêtes de recherche internes, des identifiants de compte, et parfois des jetons, et chaque pixel d’analyse et chaque police CDN sur la page est un destinataire. Les principaux navigateurs se sont convergés sur une valeur par défaut raisonnable, mais une valeur par défaut est une décision que l’agent utilisateur prend pour vous et varie selon le client ; envoyer l’en-tête rend votre politique explicite, et permet à un site manipulant des URLs sensibles de choisir quelque chose de plus strict, comme same-origin.

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

Permissions-Policy décide quelles capacités du navigateur votre document et ses cadres intégrés peuvent demander — caméra, microphone, géolocalisation, et le reste de la liste des fonctionnalités puissantes. En l’absence de l’en-tête, tout ce que vous n’avez pas désactivé est disponible pour chaque script sur la page, y compris les balises tierces que vous n’avez pas écrites. Refusez ce que vous n’utilisez pas.

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

Expédiez d’abord les 4 lignes simples, puis passez un après‑midi sur le CSP

La valeur protectrice et le risque de déploiement ne sont pas d’accord sur exactement 1 en-tête, et l’ordre de correction résout le désaccord en faveur de l’expédition.

graph TD
    A[Lisez vos propres en-têtes de réponse] --> B[Déployez 1 : HSTS avec un max‑age court]
    B --> C[Déployez 2 : nosniff, Referrer-Policy, Permissions-Policy, X-Frame-Options]
    C --> D[Étendez le max‑age de HSTS une fois que TLS est confirmé partout]
    D --> E[CSP en mode « report-only »]
    E --> F{Rapports de violation propres?}
    F -->|Non| G[Ajuster les sources, garder le mode « report-only »]
    G --> F
    F -->|Oui| H[Appliquer CSP, ajouter frame‑ancestors]

Déploiement 1 — HSTS, court. Valeur protectrice élevée, et risque quasi‑nul lorsque votre site sert déjà HTTPS partout. Définir d’abord un modest max-age afin qu’un problème TLS sur un sous‑domaine oublié reste récupérable.

Déploiement 2 — les 4 lignes statiques ensemble. nosniff, Referrer-Policy, Permissions-Policy et X-Frame-Options sont des valeurs statiques sans dépendance d’application. Ils sont 4 des 6 en-têtes et, à ces taux d’échec, la majorité de ce qu’un site moyen manque. Il n’y a aucune raison de les mettre en scène séparément.

Ensuite étendre HSTS, une fois que vous avez confirmé que chaque hôte sous le domaine sert proprement sur TLS.

Dernier — CSP, en mode « report-only ». Déployer Content-Security-Policy-Report-Only, collecter les violations depuis le trafic réel, et énumérer les sources de script et de connexion sur lesquelles vous dépendez réellement. Ce n’est qu’alors que vous passez l’en-tête en mode enforcement et ajoutez frame-ancestors à côté de votre ligne X‑Frame‑Options. Effort maximal, dernier dans la séquence, car c’est le seul élément de la liste qui peut faire tomber une page fonctionnelle.

Lire vos propres en-têtes dans la commande 1

Toute la mesure est reproductible depuis un terminal. Suivre les redirections, car la réponse finale est celle que le navigateur applique :

curl -sSL -o /dev/null -D - https://example.com/ \
  | grep -iE 'strict-transport-security|content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'

Chaque ligne qui ne revient pas est un en-tête que votre page d’accueil n’envoie pas. Toutes les 6 qui reviennent signifient que la barre de présence est effacée et que la prochaine question — si les politiques elles‑mêmes sont bonnes — vaut la peine d’être posée. Un diagnostic SEOReport payant liste chaque en‑tête absent avec la valeur qui le résout.

Les en‑têtes dans cet ensemble de données ne manquent pas parce qu’ils sont difficiles ou contestés. Ils manquent parce que rien dans la vie ordinaire d’un site web ne révèle jamais leur absence : pas d’erreur, pas de changement visuel, pas de build échoué. Les sites qui passent sont ceux où quelqu’un, une fois, est allé chercher — et ce déploiement unique est toujours disponible pour la majorité qui ne l’a pas.