Les en-têtes de sécurité que la plupart des sites ignorent encore : données provenant de 49 audits réels
Les en-têtes de réponse sont des lignes uniques de configuration livrées avec toute mise en production. Parmi les sites que nous auditons, la majorité n’en envoie aucun — Permissions-Policy est absent sur 69%, et le meilleur en-tête adopté de la liste est toujours manquant sur 41%.
Chaque audit que nous exécutons lit les en-têtes de réponse de la page d’accueil. 6 d’entre eux portent un verdict passe ou fail ; CSP en mode report-only et la paire d’isolation cross-origin sont signalés pour le contexte et ne sont jamais comptés comme échecs. La lecture se fait sur la simple requête HTTP fetch — la même capture qu’un crawler IA reçoit — et sur la réponse finale après redirections, donc un site qui définit ses en-têtes uniquement sur le saut pré-redirection ne reçoit aucune reconnaissance pour eux. La question que l’outil pose est délibérément étroite : l’en-tête était-il présent 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 n’avait 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.
La vérification demande si l’en-tête existe, pas s’il est bon
La précision de la mesure est importante ici, car elle fixe le plafond de ce que ces chiffres peuvent affirmer.
L’outil lit uniquement la page d’accueil — un URL, une réponse — et il prend les valeurs d’en-tête de la capture plain-HTTP lorsque celle-ci est disponible, en revenant à l’autre capture de la page d’accueil lorsqu’elle ne l’est pas. La présence signifie une valeur non vide. Il n’y a pas de notation des directives : un Strict-Transport-Security dont le max-age est 1 seconde passe, et il en va de même pour une Content-Security-Policy permissive assez pour autoriser tout. Rien dans un verdict passe ne dit que la politique est bien construite.
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 vérification 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.
La gravité est attribuée par en-tête plutôt que uniformément. Strict-Transport-Security et Content-Security-Policy échouent à haute gravité. X-Frame-Options, X-Content-Type-Options, Referrer-Policy et Permissions-Policy échouent à un niveau moyen. L'isolation cross-origin, la paire COOP et COEP, est uniquement informative — elle passe lorsque l'un ou l'autre en-tête est présent et, sinon, elle signale un verdict d'information, jamais un échec, car ces en-têtes contrôlent les capacités avancées du navigateur plutôt que les défenses de base.
Deux comportements valent la peine d'être connus avant de lire votre propre rapport :
- Report-only CSP ne satisfait pas la vérification CSP. Le moteur examine spécifiquement
Content-Security-Policy. Un site ne disposant que deContent-Security-Policy-Report-Onlyéchoue la vérification d'application et reçoit un verdict d'information distinct indiquant que les violations sont enregistrées mais non bloquées. Ce verdict n'existe que lorsqu'un des deux en-têtes CSP est présent. frame-ancestorsne satisfait pas la vérification X-Frame-Options. Le moteur lit l'en-têteX-Frame-Optionslui-même. Un CSP moderne avec une directiveframe-ancestorsest le meilleur contrôle, et un site qui l'inclut tout en supprimant l'en-tête hérité continuera de voir cette vérification échouer.
Il existe également une accommodation de plateforme dans le code. Lorsque la réponse provient de Vercel et que la page charge le script BotID de Vercel, un CSP manquant échoue toujours, mais à un niveau moyen plutôt qu'à un niveau élevé, avec une note expliquant que BotID nécessite des autorisations de script en ligne qui entrent en conflit avec l'application stricte du CSP. Un site peut documenter la contrainte délibérément en plaçant un commentaire HTML tel que <!-- seoreport-ignore: vercel-botid-csp --> dans les premiers 1 KB de la page d'accueil ; lorsque les noms de raison sont CSP ou BotID, la vérification passe à un verdict d'information plutôt qu'à un échec. C'est la seule échappatoire dans la famille, et elle existe parce qu'une contrainte de plateforme réelle ne doit pas être interprétée comme une négligence.
L'adoption indique 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 configure 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 dans 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 d’empêcher une catégorie de celui‑ci : 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 croient être sur votre site. Le CSP moderne exprime cela mieux avec frame-ancestors; expédiez les deux, car l’en-tête hérité est ce que les anciens clients et notre propre vérification lisent.
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 one‑liners, puis passez un après‑midi sur le CSP
La gravité du moteur 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.
Déploiement 1 — HSTS, court. Gravité maximale, et risque quasi‑nul lorsque votre site sert déjà HTTPS partout. Définir d’abord un max-age modeste afin qu’un problème TLS sur un sous‑domaine oublié reste récupérable.
Déploiement 2 — les 4 lignes de gravité moyenne ensemble. nosniff, Referrer-Policy, Permissions-Policy et X-Frame-Options sont des valeurs statiques sans dépendance d’application. Ils sont 4 des vérifications 6 et, à ces taux d’échec, la majorité de ce qu’un site moyen manque. Il n’y a aucune raison de les séparer.
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 dont 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. Gravité maximale, 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 c’est ce que fait le moteur :
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 une vérification que votre page d’accueil échoue. 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. Notre rapport gratuit effectue la même lecture sur chaque audit et 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 qu’aucun élément de la vie ordinaire d’un site web ne révèle 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.
Voir comment votre site se classe
Get a free IA-powered SEO report with actionable findings and priority fixes for your website.
Aucune inscription requise.