---
title: "État du Web 2026 : rapport sur la sécurité côté client | CentralCSP"
description: "Un recensement anonymisé de la sécurité côté client sur 761 345 domaines : qualité de configuration 96,6 sur 100, sécurité 29,2, et quoi corriger d'abord."
url: "https://centralcsp.com/fr/state-of-the-web/"
lang: "fr"
---

Recherche

Publié le 13 septembre 2026 · 761 367 domaines analysés

# État du Web 2026

Un recensement annuel et anonymisé de la sécurité côté client sur les sites que nous analysons. Il mesure l'adoption des en-têtes de réponse HTTP protecteurs, de Content-Security-Policy, des politiques modernes du navigateur et de la Reporting API, la qualité de leur configuration, les erreurs les plus fréquentes et les correctifs qui comptent le plus.

Chaque chiffre ci-dessous est une part de population sur les 761 367 domaines analysés pour cette édition. Aucune figure ne nomme un site en particulier.

**Le web tient sa configuration au propre et la laisse sans protection.** La qualité de configuration, c'est-à-dire la propreté d'écriture de chaque en-tête et de chaque politique, atteint 96,6 sur 100 en moyenne. La sécurité, c'est-à-dire la protection réellement apportée, atteint 29,2.

Ce sont deux axes distincts, pas deux degrés d'une même note. Une politique peut être écrite parfaitement et rester grande ouverte, et sur trois quarts de million de domaines c'est le cas normal.

Sécurité 29,2 /100

Qualité 96,6 /100

761 367

Domaines notés pour cette édition, chacun avec une requête GET.

152 164

Content-Security-Policies collectées et évaluées.

## Points clés

-   **Presque rien ne résiste à l'injection de script.** 108 domaines sur 761 367 réussissent, et 99,3 % sont exposés.
-   **Un site sur cinq expédie une Content-Security-Policy ; 1,5 % de ces politiques passent.** Une CSP conforme existe sur 0,29 % des domaines.
-   **Les nonces ne se sont pas imposés.** 5,3 % des politiques en utilisent un, contre 38,1 % qui autorisent encore `unsafe-inline`.
-   **Le reporting est un artefact de CDN.** 33,7 % des domaines collectent des rapports d'erreur réseau parce qu'un CDN les a activés ; 1,9 % collectent leurs propres violations CSP.
-   **Le plafond est atteignable.** Les 150 meilleurs domaines atteignent 92,4 sur 100 en moyenne, contre 46,0 pour l'ensemble du corpus.

## Comment le web se note-t-il globalement ?

Placez chaque domaine selon sa note globale et la courbe ne raconte qu'une chose : elle s'entasse au milieu et ne monte jamais. Six sites sur dix se situent dans la tranche 40-60, un tiers en dessous, et **93,4 % obtiennent moins de 60** au total.

Les deux extrémités sont presque vides. Aucun domaine du corpus ne descend sous 20, mais seuls **6,6 % dépassent 60**, et toute la tranche 80-100 tient en 3 051 domaines sur 761 367, quatre pour mille.

Ce renflement central, c'est la moyenne des deux axes : une écriture quasi parfaite tirée vers le bas par une sécurité qui se lit à peine. Un 46 ne signifie pas à moitié protégé. Il signifie bien écrit et grand ouvert.

La gaufre ci-dessous représente tout le web en 100 carrés, teintés par tranche de note. Regardez le peu de vert : 33 carrés rouges et 61 ambrés portent toute la population, et 6 carrés seulement dépassent 60.

0-20 0,0 % (0) 20-40 32,7 % (248 681) 40-60 60,7 % (462 466) 60-80 6,2 % (47 169) 80-100 0,4 % (3 051)

0-20 : 0,0 % des domaines. 20-40 : 32,7 % des domaines. 40-60 : 60,7 % des domaines. 60-80 : 6,2 % des domaines. 80-100 : 0,4 % des domaines.

Chaque carré vaut environ 1 % des 761 367 domaines, teinté selon sa tranche de note globale.

Cette courbe résume tout le rapport en une forme. Avant de la lire en-tête par en-tête, voici comment chaque note est construite.

Pour situer un domaine sur cette courbe, [comparez-le au même corpus](https://centralcsp.com/fr/tools/compare/) avec le scanner qui a produit ces chiffres.

## Comment nous avons mesuré

Chacun des 761 367 domaines a reçu une seule requête GET anonyme en HTTPS, et seuls ses en-têtes de réponse ont été analysés. L'évaluation est **passive et non intrusive** : aucune charge utile, aucun fuzzing, aucune requête modifiant l'état.

Chaque en-tête, politique et directive est évalué sur **deux axes distincts de 0 à 100** : la sécurité, est-ce que cela protège, et la qualité, est-ce proprement écrit. Les deux se combinent en une note globale.

La présence n'est pas la sûreté. Un en-tête livré et analysable n'est pas pour autant correct, et la qualité est une question différente de la sécurité, pas une version atténuée de celle-ci.

Une Content-Security-Policy bien écrite qui autorise malgré tout `unsafe-inline` obtient **une note de qualité élevée et une note de sécurité basse**. Cet exemple résume tout le rapport en une ligne.

### Comment un domaine est noté

Nous notons séparément chaque en-tête, directive, politique, endpoint de reporting et concept d'attaque, de 0 à 100. Chacun part propre et perd des points pour les problèmes trouvés, et **le pire problème** fixe la note.

L'ampleur de la perte dépend de la sévérité. Chaque constat se range dans l'un des cinq niveaux, de la faille ouverte au simple rappel :

Critique Une faille ouverte, exploitable immédiatement : exécuter du code dans la page ou détourner une session. À corriger sans délai.

Élevé Une lacune sérieuse qui expose des identifiants ou des données, ou permet une escalade. À corriger d'urgence.

Moyen Une vraie faiblesse qui affaiblit les défenses face à une attaque précise. À corriger bientôt.

Faible Un problème mineur, à impact étroit ou indirect. À ranger lors d'une maintenance normale.

Info Un rappel de qualité sans impact direct sur la sécurité. Ceux-ci façonnent la note de qualité, jamais celle de sécurité.

Ces notes par élément remontent vers les notes de catégorie et la note globale **par pondération**, pour que les contrôles les plus importants pèsent le plus. Un `script-src` faible pèse bien plus qu'un `Referrer-Policy` absent, et la même pondération agrège les en-têtes, directives et politiques pertinents dans chaque note de résistance aux attaques.

Une règle fait tout le travail en bas de l'échelle. Un contrôle obligatoire simplement absent **obtient 0** sur cet élément, à chaque fois.

Ce qui distingue un en-tête critique absent d'un en-tête mineur absent n'est pas la note mais **le poids qu'il porte**. L'obligatoire tire fortement le total vers le bas ; l'optionnel le bouge à peine.

### Ce que ces données peuvent et ne peuvent pas dire

Chaque chiffre décrit des en-têtes de réponse au moment de l'analyse, depuis une seule requête, depuis un seul point du réseau. C'est une limite réelle et elle joue dans les deux sens, autant l'énoncer avant les résultats.

**Nous sous-estimons certaines protections.** Un site qui ne pose une politique que sur ses pages authentifiées, ou qui fait varier ses en-têtes selon la route, est jugé sur la seule réponse observée. Les contrôles qui vivent dans le HTML plutôt que dans les en-têtes, comme une politique livrée par balise `meta` sur une page que nous n'avons pas chargée, nous sont invisibles.

**Nous sous-estimons aussi certains risques.** L'analyse des en-têtes ne voit pas si une page charge un script non épinglé, si un gestionnaire inline contourne la politique en pratique, ou si un nonce est bien régénéré à chaque réponse. Un en-tête conforme est un plancher, pas un certificat de bonne santé.

**La population est celle que nous analysons, pas un échantillon classé du web.** Elle penche vers les domaines qui résolvent, répondent sur le port 443 et renvoient un document, et elle n'est pas pondérée par le trafic. Un chiffre ici est une part de domaines, jamais une part de pages vues.

Un point de contrôle externe mérite d'être cité. Le Web Almanac de HTTP Archive plaçait l'adoption de CSP à 21,9 % des pages d'accueil mobiles en 2025, sur un autre corpus et avec un autre robot ; **nous mesurons 19,4 %** sur une population plus large. Deux explorations indépendantes qui tombent à deux points et demi l'une de l'autre sont une raison de faire confiance à la forme de ce qui suit.

Deux axes, cinq sévérités, un poids sur chaque contrôle, et une limite explicite sur ce qu'un en-tête peut prouver : voilà la méthode. Les sections qui suivent en lisent le résultat, d'abord les grandes classes d'attaque, puis en-tête par en-tête.

## À quel point le web est-il exposé aux grandes attaques côté client ?

Agrégez chaque en-tête, directive et politique pertinents en une note de résistance par classe d'attaque et les défenses du web disparaissent presque. **Trois des quatre vecteurs laissent plus de 97 % des sites exposés.**

La protection complète est une erreur d'arrondi. Seuls 108 domaines passent sur l'injection de script et 870 sur l'exfiltration de données ; l'altération de la chaîne d'approvisionnement n'est bloquée que sur un seul domaine de tout le corpus.

La seule exception est le clickjacking, où 7,1 % passent et un tiers de plus dispose d'une défense partielle, et uniquement parce que le correctif tient dans un vieil en-tête simple. Même là, trois sites sur cinq restent ouverts.

Chaque anneau ci-dessous agrège les en-têtes, directives et politiques qui défendent contre une classe d'attaque en un seul test, puis compte un domaine comme exposé quand cette défense est absente ou trop faible. La part verte est la barre stricte : seule une réussite complète compte comme protégée.

Exposition du corpus

Protégé 7,1 % Partiel 32,5 % Exposé 60,5 %

Exposition du corpus
| Protégé | 53 852 (7,1 %) |
| Partiel | 247 265 (32,5 %) |
| Exposé | 460 250 (60,5 %) |

Résistance moyenne 35/100

### Clickjacking

Le clickjacking charge votre page dans un cadre contrôlé par l'attaquant et pousse les utilisateurs à cliquer sur des commandes qu'ils ne voient pas. Un vieil en-tête suffit à fermer la porte : `X-Frame-Options`, ou une directive CSP `frame-ancestors`.

Le graphique montre le piège : c'est le vecteur le mieux défendu, et il reste majoritairement ouvert. Regardez la part verte, la seule des quatre assez grande pour être lisible.

Comme le correctif tient en une ligne recopiée depuis des années, c'est le seul vecteur où une part réelle du web est protégée. **Environ un site sur 14 passe (7,1 %)**, et un tiers de plus dispose d'une défense partielle (32,5 %). Les 60,5 % restants sont exposés.

Cela fixe le niveau pour la suite. Les autres grandes attaques côté client exigent une politique entière et maintenue, et là presque aucun site n'est à la hauteur. Même le clickjacking, le plus simple, ne dépasse pas 35 sur 100 de résistance moyenne.

Exposition du corpus

Protégé 0,0 % Partiel 0,7 % Exposé 99,3 %

Exposition du corpus
| Protégé | 108 (0,0 %) |
| Partiel | 5 135 (0,7 %) |
| Exposé | 756 124 (99,3 %) |

Résistance moyenne 3/100

### Injection de script

L'attaque cross-site scripting classique : un attaquant fait exécuter son propre code dans votre page, où il peut lire le DOM, récupérer des jetons de session et réécrire des formulaires. La seule chose qui la contienne de façon fiable est une Content-Security-Policy stricte : un `script-src` basé sur nonce ou hash avec `strict-dynamic`, appuyé par Trusted Types ou par du Subresource Integrity imposé, avec les points d'injection (`base-uri`, `object-src`) verrouillés.

Le graphique est presque entièrement rouge. Un domaine compte comme exposé dès que ce chemin strict est ouvert, ce qui est le cas presque partout.

Sur 761 367 domaines, **108 passent**, et moins d'un site sur 100 dispose même d'une défense partielle (0,7 %). La note de résistance moyenne s'établit à 3 sur 100.

C'est en pratique tout le web qui échoue au test le plus important face à l'attaque côté client la plus courante.

Exposition du corpus

Protégé 0,0 % Partiel 2,3 % Exposé 97,7 %

Exposition du corpus
| Protégé | 1 (0,0 %) |
| Partiel | 17 579 (2,3 %) |
| Exposé | 743 787 (97,7 %) |

Résistance moyenne 4/100

### Altération de la chaîne d'approvisionnement

La plupart des pages chargent des scripts tiers depuis des prestataires et des CDN. Si l'un de ces scripts est modifié en amont, le code modifié s'exécute dans votre page avec un accès complet. C'est le schéma des attaques Magecart de vol de cartes bancaires.

Subresource Integrity, imposé via un en-tête `Integrity-Policy` ou `require-sri-for`, est ce qui rattrape un script modifié à votre insu. Un domaine compte comme exposé quand l'intégrité n'est pas imposée et que les scripts sont approuvés sur la seule foi de leur origine.

Le chiffre se réduit à une valeur unique parce que la protection est trop rare pour être dessinée. **Exactement un domaine de tout le corpus passe**, 2,4 % de plus disposent d'une défense partielle, et la résistance moyenne est de 4 sur 100 pour 97,7 % d'exposés.

Une seule dépendance compromise s'exécuterait sans contrôle presque partout.

Exposition du corpus

Protégé 0,1 % Partiel 1,3 % Exposé 98,6 %

Exposition du corpus
| Protégé | 870 (0,1 %) |
| Partiel | 9 673 (1,3 %) |
| Exposé | 750 824 (98,6 %) |

Résistance moyenne 50/100

### Exfiltration de données cross-origin

Une fois qu'un script s'exécute dans votre page, la question suivante est de savoir où il peut envoyer ce qu'il lit. Une CSP qui fixe `connect-src`, `img-src` et `form-action` sur des hôtes connus referme les canaux sortants : fetch, balises image et envois de formulaire.

Un domaine compte comme exposé quand ces canaux sont ouverts, si bien qu'un script injecté pourrait discrètement expédier données de formulaire et jetons vers l'origine de son choix.

**870 domaines sur 761 367 passent** et 98,6 % sont exposés. Les défenses partielles viennent des 1,3 % de sites qui fixent certains canaux mais pas tous.

Ce vecteur affiche la résistance moyenne la plus élevée des quatre, 50 sur 100, et ce chiffre demande de la prudence. C'est **un crédit partiel, pas de la sûreté** : une politique qui fixe les images mais laisse `connect-src` ouvert obtient une bonne note et n'arrête rien.

Sur les quatre classes, le verdict est le même. **La protection complète est partout une erreur d'arrondi**, le seul vecteur réellement défendu le doit à un en-tête hérité, et les moyennes de résistance tiennent aux défenses partielles plutôt qu'à un rattrapage. La section suivante quitte les attaques pour demander quels en-têtes protecteurs le web envoie vraiment.

## Quels en-têtes protecteurs le web envoie-t-il vraiment ?

Classez les en-têtes de réponse protecteurs par nombre de sites qui les envoient et vous obtenez un escalier qui descend de l'automatique vers le délibéré. `Cache-Control` arrive en tête à 66,2 %, et il est là parce que l'outillage de performance le pose, pas parce que quelqu'un l'a choisi.

Les en-têtes de sécurité proprement dits occupent le milieu, chacun sur **environ deux sites sur cinq** : `X-Content-Type-Options` à 39,9 %, `X-Frame-Options` à 37,3 %, `Strict-Transport-Security` à 34,0 %. Les en-têtes cross-origin, qui demandent une vraie réflexion, tombent à 1,2 % tout en bas.

L’adoption n’est que la moitié de l’histoire. Pour la plupart des en-têtes actifs, les sites qui les envoient passent nos contrôles : `X-Content-Type-Options` passe chez **99,9 % de ses émetteurs** et `X-Frame-Options` chez 98,6 %. `Cross-Origin-Resource-Policy` fait exception : seuls **57,6 % de ses émetteurs passent**. Plus de quatre sur dix le fixent à `cross-origin`, qui accorde exactement ce qu’accorde l’absence d’en-tête : l’en-tête est présent, la protection non.

Ces en-têtes restent des interrupteurs quasi binaires. Les réussir est facile, donc le vrai signal est le petit nombre de sites qui les envoient. `Referrer-Policy` passe chez 86,7 % de ses émetteurs, `Cache-Control` chez 86,8 %.

Un en-tête rompt le schéma. Un tiers des sites envoient `Strict-Transport-Security`, mais **à peine un émetteur sur cinq l'envoie correctement** : 22,1 % des émetteurs HSTS passent, les autres livrent un `max-age` trop court ou sautent `includeSubDomains` et `preload`. 8 380 sites de plus l'envoient avec `max-age=0`, ce qui éteint purement et simplement la protection.

Cet écart résume toute la section. Rapporté au corpus entier, un HSTS pleinement correct ne touche qu'**un site sur 13 (7,5 %)**. C'est le seul en-tête largement adopté où adoption et exactitude divergent.

Le premier tableau ci-dessous est cet escalier : chaque en-tête actif par adoption, puis la note de ses émetteurs. Le second liste les en-têtes retirés encore dans la nature, où c'est l'envoi lui-même qui pose problème.

Les mêmes vérifications tournent à la demande : [testez les en-têtes que votre site envoie](https://centralcsp.com/fr/tools/security-headers/).

En-têtes de réponse protecteurs

Part des 761 367 domaines notés qui envoient chaque en-tête, et note de ces émetteurs.

| En-tête | Adoption | Réussite Partiel Échec |
| --- | --- | --- |
| Cache-Control | 66,2 % | 86,8 / 0,0 / 13,2 |
| X-Content-Type-Options | 39,9 % | 99,9 / 0,0 / 0,1 |
| X-Frame-Options | 37,3 % | 98,6 / 1,4 / 0,0 |
| Strict-Transport-Security | 34,0 % | 22,1 / 52,9 / 25,0 |
| Referrer-Policy | 26,4 % | 86,7 / 0,0 / 13,3 |
| Cross-Origin-Resource-Policy | 1,2 % | 57,6 / 42,4 / 0,0 |

Diffusion de chaque en-tête de réponse protecteur, classée par adoption.

En-têtes retirés

Les en-têtes abandonnés par la plateforme, classés par nombre de domaines qui les envoient encore.

| En-tête | Pourquoi il a été retiré | Encore envoyé par |
| --- | --- | --- |
| X-XSS-Protection | Pilotait l'auditeur XSS que tous les navigateurs ont depuis retiré ; seule la valeur 0 est sûre. | 18,6 % |
| Expect-CT | Reporting Certificate Transparency, devenu redondant depuis que CT est obligatoire. | 1,0 % |
| Feature-Policy | Renommé et remplacé par Permissions-Policy. | 0,7 % |
| Public-Key-Pins | Une seule épingle erronée pouvait bloquer l'accès au site ; remplacé par Certificate Transparency. | 0,0 % |

Les en-têtes retirés par les navigateurs, la raison de leur abandon, et le nombre de domaines qui les envoient encore.

### L'en-tête qui rend les navigateurs moins sûrs

La plupart des en-têtes absents vous coûtent une protection. Un en-tête **vous coûte une protection par sa seule présence**. `X-XSS-Protection` pilotait une fonctionnalité du navigateur, l'auditeur XSS, que tous les moteurs modernes ont depuis retirée.

L'activer (`1` ou `1; mode=block`) créait précisément les fuites d'informations cross-site qu'il était censé empêcher. La seule valeur sûre restante est `0`, qui éteint la fonctionnalité morte.

Pourtant, **près d'un cinquième du web envoie encore cet en-tête** (18,6 %, 141 522 sites). Pour ces sites, l'adoption est la régression : le correctif est de supprimer l'en-tête, pas de le configurer.

Pire, **plus de neuf émetteurs sur dix utilisent la valeur activée dangereuse** (91,0 %, 128 730 sites), exactement le mode qui a valu à la fonctionnalité d'être supprimée.

Les deux tuiles ci-dessous se lisent à l'envers. La présence est l'échec, donc l'adoption s'affiche en ambre, et la seconde tuile donne la part des émetteurs restés sur la valeur dangereuse.

18,6 %

envoient encore X-XSS-Protection

141 522 domaines sur 761 367 conservent un en-tête que tous les navigateurs actuels ont retiré.

91,0 %

d'entre eux utilisent la valeur dangereuse

128 730 domaines laissent le filtre actif (1 ou 1; mode=block), le mode qui ouvrait des fuites d'informations cross-site. La valeur sûre est 0.

Combien de domaines envoient encore X-XSS-Protection, et combien d'entre eux utilisent la valeur activée dangereuse.

### Ce que vos en-têtes révèlent

Les en-têtes protègent, mais ils révèlent aussi. Par défaut, beaucoup de piles techniques s'annoncent dans la réponse : `Server`, `X-Powered-By` et leurs cousins nomment le logiciel, et souvent la version exacte, qui tourne derrière le site.

Rien de tout cela n'est nécessaire pour servir une page, et tout cela raccourcit le travail d'un attaquant. Nommer la technologie réduit le champ de recherche ; nommer la version transforme l'en-tête en recherche directe dans les vulnérabilités publiées pour cette version.

**Environ deux sites sur cinq nomment leur pile** (39,4 %), et plus de la moitié d'entre eux impriment aussi la version (56,1 % des sites concernés), ce qui laisse environ un site sur cinq exposer la version exacte qu'il exécute (22,1 % du corpus entier).

Les deux tuiles ci-dessous découpent cette divulgation : la part de tous les sites qui nomment leur technologie, et la part plus étroite qui laisse aussi filer la version.

39,4 %

nomment leur technologie dans un en-tête

300 232 domaines annoncent ce qu'ils exécutent via Server, X-Powered-By et des en-têtes similaires.

22,1 %

exposent aussi la version exacte

168 527 domaines ajoutent aussi le numéro de version, transformant une bannière en recherche toute prête dans les vulnérabilités connues.

Sur l'ensemble du corpus, combien de domaines révèlent leur technologie dans un en-tête, et combien exposent aussi sa version.

### Les cookies posés par le web sont-ils sûrs ?

Un cookie porte la session, donc ses attributs décident de la facilité avec laquelle cette session peut être volée ou envoyée là où elle ne devrait pas aller. Trois attributs font le travail : `Secure` maintient le cookie hors des connexions en clair, `HttpOnly` le cache à JavaScript et donc à un script injecté, et `SameSite` contrôle s'il accompagne les requêtes cross-site.

Cette figure compte des cookies, pas des sites. Sur les 672 987 cookies du corpus, environ la moitié porte chaque attribut protecteur : `Secure` sur 54,3 %, `HttpOnly` sur 49,6 %, `SameSite` sur 45,5 %. **Moins de la moitié déclarent `SameSite`.**

La valeur de `SameSite` est le retournement le plus net. Parmi les cookies qui la posent, `Lax` arrive en tête avec 48,8 %, mais `None`, la valeur qui renonce à la protection cross-site, la talonne à 45,7 %, et `Strict` reste une erreur d'arrondi à 5,4 %.

Le choix de durcissement se joue donc à pile ou face entre la valeur sûre par défaut et l'abandon de la protection. Rapporté à tous les cookies du corpus, `None` concerne encore environ un cookie sur cinq (20,8 %), tandis que `Strict` reste négligeable.

Le tableau ci-dessous donne la part des cookies utilisant chaque attribut, et le graphique en dessous détaille la valeur `SameSite` parmi ceux qui en posent une.

Protections des cookies

Part des 672 987 cookies du corpus qui posent chaque attribut.

| Attribut | Ce qu'il fait | Adoption | Cookies |
| --- | --- | --- | --- |
| Secure | Envoyé uniquement en HTTPS, jamais sur une connexion en clair. | 54,3 % | 365 248 |
| HttpOnly | Invisible pour JavaScript, donc illisible par un script injecté. | 49,6 % | 333 599 |
| SameSite | Limite les cas où le cookie accompagne une requête cross-site. | 45,5 % | 305 897 |

Valeur SameSite, quand elle est posée

Aucun 45,8 % Lax 48,8 % Strict 5,4 %

Valeur SameSite, quand elle est posée
| Aucun | 139 940 (45,8 %) |
| Lax | 149 181 (48,8 %) |
| Strict | 16 612 (5,4 %) |

Parmi les cookies du corpus, la part qui pose chaque attribut protecteur, et la valeur SameSite choisie par ceux qui en posent une.

Sur les quatre figures, le même défaut se répète : un en-tête envoyé n'est pas un en-tête correctement réglé. Les en-têtes faciles sont presque parfaits ; **ceux qui portent la charge ne le sont pas**. Là où la valeur porte un vrai poids de sécurité, HSTS, `SameSite` et les en-têtes retirés montrent combien souvent le choix joue contre le site.

Cela mène droit au seul contrôle conçu pour contenir l'injection de script, et à la façon dont le web le construit.

## Comment la Content-Security-Policy est-elle réellement construite ?

Content-Security-Policy est le seul contrôle du web qui contienne de façon fiable une injection de script une fois qu'elle a lieu. Environ un site sur cinq en envoie une, et presque aucun n'en envoie une sûre.

Les quatre graphiques ci-dessous posent tout le problème : combien de domaines expédient une CSP, comment ces politiques se notent en sécurité, comment elles sont livrées, et si elles imposent ou se contentent d'observer.

Adoption

Expédie une CSP 19,4 % Sans CSP 80,6 %

Adoption
| Expédie une CSP | 148 000 (19,4 %) |
| Sans CSP | 613 367 (80,6 %) |

Résultat de sécurité

Réussite 1,5 % Partiel 7,1 % Échec 91,4 %

Résultat de sécurité
| Réussite | 2 251 (1,5 %) |
| Partiel | 10 446 (7,1 %) |
| Échec | 135 303 (91,4 %) |

Mode de livraison

En-tête 96,0 % Les deux 1,2 % Balise meta 2,7 %

Mode de livraison
| En-tête | 146 113 (96,0 %) |
| Les deux | 1 887 (1,2 %) |
| Balise meta | 4 164 (2,7 %) |

Mode

Appliqué 89,5 % Les deux 2,7 % Rapport uniquement 7,8 %

Mode
| Appliqué | 132 467 (89,5 %) |
| Les deux | 3 977 (2,7 %) |
| Rapport uniquement | 11 556 (7,8 %) |

Combien de domaines expédient une Content-Security-Policy, comment ces politiques se notent, et comment elles sont livrées et appliquées.

L'adoption est la moitié facile. **19,4 % du web expédie une CSP** (148 000 domaines sur 761 367), et ces politiques sont propres : elles atteignent 98 sur 100 en qualité.

Puis le contrôle de sécurité s'exécute et le plancher cède. Parmi les politiques que nous évaluons, **91,4 % échouent** (135 303 sites) et seulement 1,5 % passent (2 251 sites).

Les mêmes politiques qui obtiennent 98 en propreté d'écriture atteignent **29 en sécurité**. Propres, et inutiles.

Ce sont de vraies politiques, pas des essais. Presque toutes tournent en mode appliqué plutôt qu'en report-only (89,5 %), et **96,0 % arrivent dans un en-tête**, seuls 2,7 % reposant sur une balise meta. L'en-tête est là ; la protection ne l'est pas.

À l'échelle du corpus, une CSP conforme existe sur **0,29 % des domaines**. Moins de trois sites sur mille disposent du contrôle qui contiendrait l'attaque côté client la plus courante.

L'écart entre la qualité d'écriture et la sécurité, c'est exactement ce à quoi ressemble une politique écrite à la main. [La construire à partir des rapports navigateur](https://centralcsp.com/fr/platform/csp-builder/) le comble, parce que les directives viennent de ce que vos visiteurs chargent réellement.

### Quelles directives les politiques posent-elles, et avec quel résultat ?

Une Content-Security-Policy est une liste de directives, et elles ne pèsent pas toutes pareil. Les sites réussissent les moins chères et ratent les dangereuses.

`frame-ancestors` mène l'adoption avec 54,9 % des sites à CSP et passe dans 76,9 % des cas, parce qu'elle fait une seule chose bien délimitée. `script-src`, la directive qui contrôle réellement les scripts injectés, apparaît sur 40,5 % des sites à CSP et **échoue dans 89,1 % des cas** (45 390 usages sur 50 916).

Le schéma se poursuit dans tout le tableau. Les directives qui contraignent scripts et styles échouent le plus (`style-src` passe dans 9,3 % des cas, `script-src-elem` dans 2,7 %), tandis que les structurelles passent facilement : `base-uri` passe à 91,6 %, et `upgrade-insecure-requests` passe partout où elle apparaît.

**La difficulté de CSP tient aux deux ou trois directives qui contiennent vraiment une attaque**, pas au fait de les énumérer. Les directives modernes de durcissement se lisent à peine en bas de tableau : `require-trusted-types-for` apparaît sur 285 sites à CSP, `trusted-types` sur 166.

Le tableau ci-dessous classe chaque directive canonique par fréquence d'apparition, puis note chacune : sur ses usages, combien passent, passent partiellement, ou échouent. Regardez l'écart entre les directives `*-src` très utilisées et leur taux d'échec.

Directives CSP

Part des 152 164 domaines livrant une CSP qui posent chaque directive, et note de ces usages.

| Directive | Utilisé | Réussite Partiel Échec |
| --- | --- | --- |
| frame-ancestors | 54,9 % | 76,9 / 13,5 / 9,6 |
| default-src | 41,8 % | 53,0 / 2,4 / 44,6 |
| script-src | 40,5 % | 6,4 / 4,4 / 89,1 |
| img-src | 37,9 % | 17,2 / 3,0 / 79,8 |
| style-src | 34,8 % | 9,3 / 49,6 / 41,2 |
| font-src | 34,4 % | 71,6 / 4,8 / 23,6 |
| connect-src | 34,2 % | 17,7 / 1,1 / 81,1 |
| upgrade-insecure-requests | 33,2 % | 100,0 / 0,0 / 0,0 |
| frame-src | 30,6 % | 26,4 / 15,1 / 58,5 |
| object-src | 28,4 % | 76,5 / 0,0 / 23,5 |
| base-uri | 26,3 % | 91,6 / 0,0 / 8,4 |
| form-action | 19,4 % | 68,1 / 5,0 / 27,0 |
| media-src | 17,8 % | 64,2 / 4,1 / 31,7 |
| worker-src | 14,9 % | 63,0 / 1,0 / 36,0 |
| child-src | 8,2 % | 0,0 / 49,2 / 50,8 |
| report-uri | 7,8 % | 99,1 / 0,8 / 0,1 |
| manifest-src | 7,3 % | 74,3 / 18,8 / 6,8 |
| block-all-mixed-content | 4,2 % | 0,0 / 100,0 / 0,0 |
| script-src-elem | 3,3 % | 2,7 / 4,7 / 92,6 |
| report-to | 3,0 % | 99,6 / 0,2 / 0,2 |
| style-src-elem | 2,1 % | 10,6 / 45,2 / 44,3 |
| script-src-attr | 2,0 % | 48,0 / 2,4 / 49,7 |
| style-src-attr | 1,3 % | 7,7 / 87,1 / 5,1 |
| require-trusted-types-for | 0,2 % | 99,3 / 0,7 / 0,0 |
| prefetch-src | 0,1 % | 0,0 / 80,7 / 19,3 |
| sandbox | 0,1 % | 4,1 / 2,6 / 93,4 |
| trusted-types | 0,1 % | 30,1 / 62,0 / 7,8 |
| fenced-frame-src | 0,0 % | 0,0 / 70,0 / 30,0 |
| navigate-to | 0,0 % | 0,0 / 96,4 / 3,6 |
| plugin-types | 0,0 % | 0,0 / 100,0 / 0,0 |
| referrer | 0,0 % | 0,0 / 100,0 / 0,0 |
| reflected-xss | 0,0 % | 0,0 / 100,0 / 0,0 |
| require-sri-for | 0,0 % | 0,0 / 100,0 / 0,0 |
| webrtc | 0,0 % | 0,0 / 100,0 / 0,0 |

Fréquence d'apparition de chaque directive CSP dans les politiques, et qualité de ces usages.

### Ce qui durcit une politique, et ce qui l'affaiblit

Qu'une politique protège ou non dépend des mots-clés qu'elle contient, et les auteurs de CSP choisissent les mauvais. Les mots-clés affaiblissants **dépassent largement les durcissants**.

`unsafe-inline` apparaît sur 38,1 % des sites à CSP et `unsafe-eval` sur 33,0 %. Les nonces, le mécanisme de durcissement phare, atteignent **5,3 %**. Environ sept fois plus de politiques autorisent les scripts inline qu'elles ne les verrouillent par un nonce.

C'est pire sous la surface. `strict-dynamic`, le mot-clé qui rend une politique à nonce vraiment difficile à contourner, tient sur **2,5 % des sites à CSP** (3 853 politiques). Trusted Types, la meilleure défense que la plateforme offre contre l'injection dans le DOM, n'est imposé que sur 348.

La liste des affaiblissements va aussi plus loin que les deux mots-clés célèbres. Plus d'une politique sur cinq autorise un endpoint JSONP connu (22,1 %) ou un script gadget connu (21,2 %), qui offrent tous deux à un attaquant un contournement d'une liste blanche par ailleurs raisonnable.

Les deux tableaux ci-dessous séparent les mécanismes qui durcissent une politique de ceux qui l'affaiblissent, chacun en part des sites livrant une CSP. Lisez-les par paire : la colonne verte est courte, la rouge ne l'est pas.

Mécanisme de durcissement

Part des 152 164 domaines livrant une CSP.

| Mécanisme de durcissement | Domaines | Durcissement |
| --- | --- | --- |
| upgrade-insecure-requests | 50,5k | 33,2 % |
| Nonces | 8k | 5,3 % |
| strict-dynamic | 3,9k | 2,5 % |
| Hashs | 2,9k | 1,9 % |
| Trusted Types (imposé) | 348 | 0,2 % |
| Trusted Types (déclaré) | 203 | 0,1 % |

Les mécanismes qui renforcent une politique, chacun en part des domaines livrant une CSP.

Mécanisme d'affaiblissement

Part des 152 164 domaines livrant une CSP.

| Mécanisme d'affaiblissement | Domaines | Affaiblissement |
| --- | --- | --- |
| unsafe-inline | 58k | 38,1 % |
| unsafe-eval | 50,3k | 33,0 % |
| Endpoint JSONP | 33,6k | 22,1 % |
| Script gadget | 32,2k | 21,2 % |
| Joker de sous-domaine | 28,1k | 18,4 % |
| Source de schéma | 27,3k | 17,9 % |
| Hôte mutualisé | 17,7k | 11,7 % |
| Joker complet \* | 5,6k | 3,7 % |
| wasm-unsafe-eval | 1,9k | 1,2 % |
| unsafe-hashes | 842 | 0,6 % |

Les mécanismes qui affaiblissent une politique, chacun en part des domaines livrant une CSP.

### Qu'est-ce qui cloche dans les politiques existantes ?

Même quand les politiques sont brouillonnes, le désordre est surtout inoffensif. **L'erreur d'écriture la plus fréquente touche 8,1 % des sites à CSP**, et c'est une valeur source répétée deux fois dans la même directive.

En dessous, la liste reste à un seul chiffre : un mot-clé utilisé dans une directive qui l'ignore (6,2 %), une source déjà couverte par une plus large (6,1 %), une directive dépréciée recopiée d'un vieux modèle (4,3 %). Ce sont des problèmes d'hygiène, pas des trous.

Celles qui mordent vraiment sont rares, et c'est précisément pour cela qu'elles survivent. Environ un site à CSP sur 89 écrit un mot-clé sans ses guillemets (1,1 %), si bien que `unsafe-inline` ou `self` est interprété comme un nom d'hôte et la directive signifie silencieusement autre chose que ce que l'auteur a écrit.

**CSP ne renvoie presque aucun retour à ses auteurs**, donc ces erreurs ne sont jamais rattrapées. Rien dans un navigateur ne vous dit que votre politique a été interprétée autrement que ce que vous avez écrit.

Le tableau ci-dessous classe les dix erreurs d'écriture les plus fréquentes par nombre de sites à CSP touchés, en part des sites livrant une CSP.

Erreurs d'écriture de CSP

Part des 152 164 domaines livrant une CSP touchés par chaque erreur.

| Erreur d'écriture | Domaines | Part des sites à CSP |
| --- | --- | --- |
| Valeur en double dans une directive | 12,3k | 8,1 % |
| Mot-clé non valide dans cette directive | 9,4k | 6,2 % |
| Source déjà couverte par une plus large | 9,2k | 6,1 % |
| Directive dépréciée | 6,5k | 4,3 % |
| Valeur source sans effet | 3,9k | 2,6 % |
| Plusieurs en-têtes CSP | 3,7k | 2,5 % |
| La directive autorise localhost | 2,9k | 1,9 % |
| Politique envoyée à la fois par balise meta et par en-tête | 1,9k | 1,2 % |
| Mot-clé sans ses guillemets | 1,7k | 1,1 % |
| Directive inconnue | 1,2k | 0,8 % |

Les erreurs d'écriture les plus fréquentes dans les politiques existantes, par nombre de sites à CSP touchés.

L'adoption de CSP est réelle, mais un en-tête présent n'est pas une défense qui fonctionne. **Neuf politiques sur dix échouent**, et les directives qui arrêtent l'injection de script sont exactement celles que les auteurs ratent. La section suivante quitte CSP pour examiner le déploiement des autres politiques modernes.

## Quelle est la diffusion des autres politiques ?

La politique la plus déployée du web n'est pas un contrôle de sécurité. Network Error Logging touche **33,7 % des domaines**, devant Content-Security-Policy à 19,4 %, et y parvient parce que les CDN l'activent, pas parce que des exploitants l'ont choisie.

Sous CSP, les en-têtes modernes s'amincissent vite. COOP touche 9,8 % et Permissions-Policy 9,1 %, environ un site sur onze. COEP, la seconde moitié de l'isolation cross-origin, atteint **0,6 % des sites**.

Comme l'isolation réelle exige à la fois COOP et COEP, ce chiffre de COEP est le vrai plafond, quel que soit le nombre de sites posant COOP seul. COEP est dix-sept fois plus rare que son binôme, donc **presque aucun déploiement de COOP ne peut atteindre l'isolation**.

Les politiques réellement nouvelles se lisent à peine. Document-Policy est à 0,1 % (720 domaines), tandis qu'Integrity-Policy et Connection-Allowlist tiennent en une poignée, **16 domaines et 6**. Ce sont des fonctionnalités livrées par les navigateurs sans adoption de terrain, une frontière qu'il vaut la peine de nommer pour que l'an prochain ait une base de comparaison.

Le tableau ci-dessous classe chaque politique par la part du corpus qui la déploie, puis découpe chacune par mode : appliqué, les deux, ou report-only. Notez que le report-only est quasiment abandonné ; toute politique largement posée est **appliquée dès le premier jour**.

Adoption des politiques modernes

Part des 761 367 domaines notés qui déploient chaque politique.

| Politique | Déployé | Appliqué Les deux Rapport uniquement |
| --- | --- | --- |
| Network Error Logging | 33,7 % | 100,0 / 0,0 / 0,0 |
| Content-Security-Policy | 19,4 % | 89,5 / 2,7 / 7,8 |
| Cross-Origin-Opener-Policy | 9,8 % | 98,7 / 1,1 / 0,2 |
| Permissions-Policy | 9,2 % | 100,0 / 0,0 / 0,0 |
| Cross-Origin-Embedder-Policy | 0,6 % | 76,8 / 19,2 / 4,0 |
| Document-Policy | 0,1 % | 99,4 / 0,1 / 0,4 |
| Connection-Allowlist | 0,0 % | 20,0 / 0,0 / 80,0 |
| Integrity-Policy | 0,0 % | 31,3 / 0,0 / 68,8 |

Diffusion de chaque politique moderne, et pour chacune si ses déployeurs l'appliquent, cumulent les deux modes, ou se contentent de surveiller.

Le déploiement n'est que la moitié du tableau. Le graphique ci-dessous montre, parmi les sites qui déploient chaque politique, combien passent nos contrôles de sécurité, atterrissent en partiel, ou échouent, triés pour que le pire taux d'échec soit à gauche.

Une barre se détache. **CSP échoue sur 91,4 % des politiques évaluées** et passe sur 1,5 %. Toute autre politique largement déployée passe presque à chaque fois qu'elle est posée : Permissions-Policy à 100 %, NEL à 100 %, COOP à 90,9 %.

COEP est le cas intermédiaire intéressant. Elle ne passe que chez 19,9 % de ses déployeurs, les 80,1 % restants atterrissant en partiel, parce que poser COEP sans la valeur COOP qui complète l'isolation vous donne un en-tête et pas la garantie.

Une partie de l'écart de CSP tient à ce que la politique peut exprimer. CSP est notée sur un barème exigeant, une liste blanche riche qui peut être présente et pourtant non sûre. Les autres sont quasi binaires, où présent et bien formé vaut réussite, donc le contraste **mesure la difficulté de la politique** autant que le savoir-faire de l'exploitant.

Lisez les plus petites barres avec prudence. Les taux de Document-Policy, Integrity-Policy et Connection-Allowlist reposent sur quelques déployeurs chacun, pas sur une population, donc leurs barres sont **des anecdotes, pas des tendances**.

Réussite Partiel Échec

Santé des politiques
| Politique | Réussite | Partiel | Échec |
| --- | --- | --- | --- |
| CSP | 1.5% | 7.1% | 91.4% |
| NEL | 100% | 0% | 0% |
| COOP | 90.9% | 9.1% | 0% |
| Permissions | 100% | 0% | 0% |
| COEP | 19.9% | 80.1% | 0% |
| Document | 98.6% | 1.4% | 0% |
| Connection | 100% | 0% | 0% |
| Integrity | 40% | 60% | 0% |

Parmi les sites qui déploient chaque politique et peuvent être évalués, combien passent, passent partiellement, ou échouent à nos contrôles de sécurité. Les barres sont triées par taux d'échec.

CSP est la seule politique largement déployée qui échoue majoritairement. **Un cinquième du web la met en place**, la garde assez propre pour l'appliquer, et la laisse malgré tout ouverte. La section suivante demande qui peut seulement voir ces échecs quand ils surviennent.

## Quelqu'un voit-il vraiment les violations ?

Sur le papier, environ **un tiers du web** est câblé pour remonter les problèmes à ses exploitants. La quasi-totalité est de la journalisation d'erreurs réseau, activée automatiquement par les CDN plutôt que choisie par un propriétaire de site.

Retirez cette journalisation automatique et le signal délibéré est faible. Network Error Logging est configuré sur 256 658 domaines ; tous les autres types de rapport qu'un site choisirait vraiment totalisent **19 907 domaines** à eux tous.

Le rapport qui compte le plus est le plus rare des courants. **1,9 % du corpus** collecte ses propres violations de Content-Security-Policy : 14 197 domaines, le seul retour qui vous dise que votre politique casse de vraies pages.

Le reporting est aussi le rare endroit où configuration et livraison divergent, et ce sont les politiques récentes qui cassent. Sur les 1 112 domaines qui câblent le reporting COOP, **81,3 % l'ont cassé**, et le reporting COEP est cassé sur 92,4 % des 1 005 qui essaient.

Le reporting CSP se porte mieux : 97,5 % des domaines qui le configurent reçoivent bien des rapports. **Le web ne regarde pas ses propres violations, et là où il essaie sur les politiques récentes, il configure généralement mal l'endpoint.**

Ce que « cassé » signifie mérite d'être précisé. Une ligne n'est cassée que lorsque la politique **désigne une destination que le navigateur ne peut pas atteindre** ; une politique qui retombe silencieusement sur le groupe par défaut et n'y trouve rien est comptée comme non configurée, jamais comme cassée.

C'est cette distinction qui coule COOP et COEP. Ni l'une ni l'autre ne peut désigner une URL : toutes deux pointent vers un groupe `report-to` qui doit être déclaré séparément dans un en-tête `Reporting-Endpoints`, si bien que l'échec ordinaire est une ligne recopiée d'un guide avec son `report-to="coop"` intact et aucun groupe déclaré derrière.

**La CSP échappe en grande partie à cela** parce que `report-uri` désigne une URL directement, sans second en-tête à oublier. L'écart entre 97,5 % de fonctionnel pour la CSP et 7,6 % pour COEP tient largement à cette seule différence de conception, pas à un soin inégal apporté à la configuration.

Le tableau ci-dessous classe chaque type de rapport par la part du corpus qui le configure, puis découpe chaque ligne en endpoints fonctionnels et cassés. Deux dénominateurs cohabitent : la part de configuration porte sur le corpus entier, mais le partage entre fonctionnel et cassé porte sur le total de configuration de la ligne.

Collecte des rapports

La part de configuration porte sur l'ensemble des 761 367 domaines ; les colonnes fonctionnel et cassé découpent le total de la ligne.

| Type de rapport | Configuré pour remonter | Fonctionnel Cassé |
| --- | --- | --- |
| Erreur réseau | 33,7 % | 100,0 / 0,0 |
| Violation CSP | 1,9 % | 97,5 / 2,5 |
| Rapport COOP | 0,1 % | 18,7 / 81,3 |
| Plantage | 0,1 % | 96,8 / 3,2 |
| Dépréciation | 0,1 % | 96,8 / 3,2 |
| Intervention | 0,1 % | 96,8 / 3,2 |
| Violation COEP | 0,1 % | 7,6 / 92,4 |
| Violation Permissions-Policy | 0,1 % | 99,2 / 0,8 |
| Rapport de hash de script CSP | 0,0 % | 95,2 / 4,8 |
| Violation d'intégrité | 0,0 % | 92,3 / 7,7 |
| Violation Document-Policy | 0,0 % | 77,8 / 22,2 |
| Connection-Allowlist | 0,0 % | 100,0 / 0,0 |

Chaque type de rapport par la part du corpus qui le configure. Les colonnes fonctionnel et cassé découpent le total de la ligne, pas le corpus.

### Report-To ou Reporting-Endpoints ?

Il y a deux façons d'indiquer à un navigateur où envoyer les rapports. `Reporting-Endpoints` est le standard actuel ; `Report-To` est l'en-tête plus ancien qu'il remplace et qui est désormais déprécié.

Le graphique ci-dessous ne regarde que les sites qui déclarent l'un ou l'autre, et l'équilibre est très déséquilibré. Parmi eux, **98,1 % utilisent encore `Report-To` déprécié**, et 1,9 % sont passés à l'en-tête moderne.

Cette part dépréciée est la même plomberie de CDN déjà comptée plus haut. `Report-To` est présent sur 34,1 % du corpus, à peu près la même part que la journalisation d'erreurs réseau, parce qu'il s'agit d'**un seul mécanisme injecté par les CDN** plutôt que d'un choix fait site par site.

Le `Reporting-Endpoints` moderne a à peine atterri : 5 065 sites, 0,7 % du corpus, environ un site sur 151.

Le brancher tient en un en-tête de réponse, et [collecter ce que les navigateurs renvoient](https://centralcsp.com/fr/platform/monitoring/) est la source des chiffres de cette section.

Domaines déclarant un en-tête de reporting

Reporting-Endpoints 1,9 % Report-To (déprécié) 98,1 %

Domaines déclarant un en-tête de reporting
| Reporting-Endpoints | 5 065 (1,9 %) |
| Report-To (déprécié) | 259 388 (98,1 %) |

Parmi les domaines qui déclarent un en-tête de destination de rapports, la répartition entre le moderne Reporting-Endpoints et le déprécié Report-To.

Le web ne peut pas voir ce qu'il ne regarde pas. Hors de la journalisation que les CDN activent pour lui, **le reporting délibéré se lit à peine**, et sur les politiques les plus récentes la plupart de ceux qui essaient se trompent d'endpoint. La section suivante passe du diagnostic à la prescription.

## Que corriger en premier ?

157 constats distincts ne font pas un plan. Pondérez chacun par les dégâts qu'il cause et par le nombre de sites qu'il touche, et une courte liste de priorités se dégage.

Les trois recommandations de plus forte sévérité se résument à une phrase : posez une vraie CSP. Les constats d'injection de script (99,2 %), de chaîne d'approvisionnement (98,9 %) et d'exfiltration de données (98,6 %) touchent chacun **environ 99 % des sites**.

Les trois sont la même situation sous trois masques. Une page sans vraie CSP ne restreint rien, donc elle échoue aux trois d'un coup. Le geste le plus rentable du web est donc aussi le plus élémentaire : **déployez une politique, puis resserrez-la**.

Sous ces constats de tête, la liste change de nature. Les correctifs destinés aux sites qui ont déjà une CSP mais l'ont affaiblie touchent bien moins de domaines : **environ un site sur sept** laisse `connect-src` assez ouvert pour exfiltrer librement (15,1 %), et 7,4 % autorisent encore `unsafe-inline` dans `script-src`.

Viennent ensuite les recommandations bon marché d'en-têtes manquants, qui touchent presque tout le monde mais élèvent rarement l'enjeu, et enfin les politiques émergentes que presque personne n'expédie.

Un point mérite d'être dit pour ce qu'il n'est pas. **Le catalogue ne contient aucun constat critique cette année.** Rien dans le corpus ne déclenche notre sévérité maximale, et les dégâts sont portés entièrement par 21 constats de sévérité haute, dont trois touchent presque tous les sites du web.

Le tableau ci-dessous classe les principales recommandations par pertinence, dégâts multipliés par portée, pour que les correctifs les plus dommageables et les plus répandus arrivent en premier.

Recommandations prioritaires

Les 157 constats du catalogue, pondérés par sévérité et par portée, sur l'ensemble des 761 367 domaines.

| Priorité | Recommandation | Sévérité | Domaines | Part du corpus |
| --- | --- | --- | --- | --- |
| À faire maintenant | Ajoutez un script-src strict basé sur un nonce avec 'strict-dynamic'. | Élevé | 755,1k | 99,2 % |
| À faire maintenant | Ajoutez un en-tête Integrity-Policy pour exiger le SRI sur les scripts. | Élevé | 752,9k | 98,9 % |
| À faire maintenant | Définissez connect-src à 'self' et à vos hôtes connus. | Élevé | 750,7k | 98,6 % |
| Corriger votre CSP | Restreignez connect-src à 'self' et à vos hôtes d'API/analytics. | Élevé | 114,6k | 15,1 % |
| Corriger votre CSP | Retirez 'unsafe-inline' ; utilisez un nonce avec 'strict-dynamic'. | Élevé | 56,6k | 7,4 % |
| Corriger votre CSP | Retirez 'unsafe-eval' de la directive. | Élevé | 50,3k | 6,6 % |
| Corriger votre CSP | Retirez le schéma dangereux de la directive. | Élevé | 33,8k | 4,4 % |
| Corriger votre CSP | Retirez l'hôte JSONP de la directive. | Élevé | 32,8k | 4,3 % |
| Corriger votre CSP | Retirez l'hôte de script gadget de la directive. | Élevé | 31,6k | 4,1 % |
| Corriger votre CSP | Remplacez l'hôte mutualisé par un hôte dédié que vous contrôlez. | Élevé | 17,6k | 2,3 % |
| Corriger votre CSP | Déplacez la CSP vers l'en-tête appliqué. | Élevé | 11,5k | 1,5 % |
| Corriger votre CSP | Retirez la source de schéma de la directive. | Élevé | 10,9k | 1,4 % |
| À faire maintenant | Remplacez max-age=0 par max-age=31536000. | Élevé | 8,4k | 1,1 % |
| Corriger votre CSP | Remplacez default-src \* par 'self'/'none' et définissez les sources par directive. | Élevé | 4,7k | 0,6 % |
| Corriger votre CSP | Remplacez le joker de la directive par une politique à nonce. | Élevé | 3,5k | 0,5 % |
| Corriger votre CSP | Générez un nonce neuf à chaque réponse. | Élevé | 1,4k | 0,2 % |
| Recommandé | Ajoutez un en-tête Permissions-Policy désactivant les fonctions inutilisées. | Moyen | 691,2k | 90,8 % |
| Corriger votre CSP | Ajoutez une CSP stricte basée sur un nonce. | Moyen | 609,2k | 80,0 % |
| Recommandé | Ajoutez un en-tête NEL avec un groupe report\_to déclaré dans Report-To. | Moyen | 504,7k | 66,3 % |
| Recommandé | Déclarez un groupe Reporting-Endpoints et référencez-le. | Moyen | 499,7k | 65,6 % |

157 constats pondérés par sévérité et par portée, les correctifs les plus rentables en premier.

Tout le catalogue se ramène à une priorité : **mettez en place une vraie CSP**, puis fermez les directives qui affaiblissent les politiques existantes. Le reste est la longue traîne. La section suivante quitte les échecs pour demander ce que font différemment les sites les mieux configurés.

## Quelle distance sépare les meilleurs du reste ?

Une petite élite prouve qu'une note quasi parfaite est atteignable. Les 150 meilleurs domaines atteignent **92,4 sur 100** en moyenne ; l'ensemble des 761 367 atteint 46,0. Soit un écart de 46,4 points, l'équivalent d'une seconde fois la note typique.

Décomposez cet écart par axe et il se révèle tenir à un seul axe. En qualité, les deux populations sont presque indiscernables : **97,5 pour la cohorte des meilleurs contre 96,6 pour tous les autres**, moins d'un point de différence.

En sécurité, ce ne sont plus les mêmes webs. La cohorte des meilleurs atteint **90,9 sur 100** contre 29,2 pour la moyenne du corpus, un gouffre de 61,5 points. Toute la distance entre les deux populations se loge sur ce seul axe.

L'élite n'est donc pas plus soigneuse que les autres. Elle est **protégée**, et les autres ne le sont pas, alors que les deux tiennent leur configuration à peu près dans le même ordre.

Les trois cartes ci-dessous comparent la cohorte des mieux configurés au corpus entier sur la note globale. La section qui suit décompose ce chiffre unique, domaine par domaine.

Moyenne de la cohorte des meilleurs 92,4 /100

Moyenne du corpus 46,0 /100

L'écart +46,4 pts

Les 150 domaines les mieux configurés face à l'ensemble des 761 367, sur la note globale de 0 à 100.

### Où les meilleurs creusent l'écart, domaine par domaine

Les cartes ci-dessus comparent les deux populations sur un seul chiffre ; ces radars montrent où se loge vraiment la différence. Chacun oppose la cohorte des 150 sites les mieux configurés à la moyenne des 761 367 domaines, chaque branche étant une sous-note de 0 à 100.

Les deux séries n'ont pas la même taille. Le vert représente **moins d'un site sur 5 000**. L'ambre, c'est tout le web, la vraie référence.

La même forme se répète sur chaque panneau : un anneau vert poussé près du bord, posé sur un cœur ambre effondré. L'écart est catégoriel, pas graduel.

Sur CSP, la cohorte des meilleurs atteint 98 contre 7 pour la moyenne, un rapport de quatorze et le plus large de tous. La résistance aux attaques donne 88 contre 23, et les politiques 61 contre 15, soit **environ quatre fois la moyenne** dans les deux cas.

Deux domaines vont à contre-courant. Les en-têtes de sécurité sont le seul endroit où la moyenne dépasse la moitié, 54 sur 100, et seulement parce que les **en-têtes bon marché que presque tout le monde envoie déjà** la soutiennent.

La configuration du reporting est l'inverse. Même la cohorte des meilleurs n'atteint que **8 sur 100**, c'est donc le seul axe où être le meilleur revient encore à ce que presque personne ne s'en occupe. Lisez une branche proche de zéro avec prudence : elle peut signifier que le contrôle est simplement absent plutôt que mal configuré.

Meilleurs sites Moyenne du corpus

En-têtes de sécurité

En-têtes de sécurité
| En-têtes de sécurité | Meilleurs sites | Moyenne du corpus | Domaines mesurés |
| --- | --- | --- | --- |
| X-Content-Type-Options | 100/100 | 40/100 | 761 367 |
| Referrer-Policy | 100/100 | 24/100 | 761 367 |
| Cache-Control | 99/100 | 92/100 | 505 415 |
| Strict-Transport-Security | 99/100 | 23/100 | 750 390 |
| Cross-Origin-Resource-Policy | 98/100 | 83/100 | 9 067 |

Résistance aux attaques

Résistance aux attaques
| Résistance aux attaques | Meilleurs sites | Moyenne du corpus | Domaines mesurés |
| --- | --- | --- | --- |
| Clickjacking | 99/100 | 35/100 | 761 367 |
| Exfiltration de données | 99/100 | 50/100 | 761 367 |
| Injection de script | 82/100 | 3/100 | 761 367 |
| Chaîne d'appro. | 70/100 | 4/100 | 761 367 |

Politiques Reporting-API

Politiques Reporting-API
| Politiques Reporting-API | Meilleurs sites | Moyenne du corpus | Domaines mesurés |
| --- | --- | --- | --- |
| Integrity-Policy | 100/100 | 82/100 | 5 |
| Permissions-Policy | 96/100 | 9/100 | 761 346 |
| Document-Policy | 94/100 | 100/100 | 717 |
| Cross-Origin-Opener-Policy | 71/100 | 10/100 | 761 213 |
| Content-Security-Policy | 61/100 | 47/100 | 148 000 |
| Cross-Origin-Embedder-Policy | 45/100 | 0/100 | 761 206 |
| Network Error Logging | 30/100 | 34/100 | 761 367 |
| Connection-Allowlist | 0/100 | 100/100 | 1 |

Configuration Reporting-API

Configuration Reporting-API
| Configuration Reporting-API | Meilleurs sites | Moyenne du corpus | Domaines mesurés |
| --- | --- | --- | --- |
| Violation CSP | 36/100 | 2/100 | 761 367 |
| Erreur réseau | 28/100 | 34/100 | 761 367 |
| Plantage | 6/100 | 0/100 | 761 367 |
| Dépréciation | 6/100 | 0/100 | 761 367 |
| Intervention | 6/100 | 0/100 | 761 367 |
| Violation Permissions-Policy | 5/100 | 0/100 | 761 367 |
| Rapport COOP | 4/100 | 0/100 | 761 367 |
| Violation COEP | 3/100 | 0/100 | 761 367 |
| Connection-Allowlist | 1/100 | 0/100 | 761 367 |
| Rapport de hash de script CSP | 1/100 | 0/100 | 761 367 |
| Violation Document-Policy | 1/100 | 0/100 | 761 367 |
| Violation d'intégrité | 1/100 | 0/100 | 761 367 |

Content Security Policy

Directive expérimentale Directive dépréciée

Content Security Policy
| Content Security Policy | Meilleurs sites | Moyenne du corpus | Domaines mesurés |
| --- | --- | --- | --- |
| base-uri | 100/100 | 20/100 | 146 602 |
| default-src | 100/100 | 25/100 | 143 920 |
| font-src | 100/100 | 27/100 | 132 731 |
| form-action | 100/100 | 12/100 | 147 670 |
| frame-ancestors | 100/100 | 87/100 | 76 310 |
| frame-src | 100/100 | 17/100 | 130 194 |
| manifest-src | 100/100 | 7/100 | 95 459 |
| media-src | 100/100 | 15/100 | 112 749 |
| report-to | 100/100 | 99/100 | 3 088 |
| report-uri | 100/100 | 100/100 | 8 478 |
| require-trusted-types-for | 100/100 | 100/100 | 287 |
| script-src | 100/100 | 10/100 | 142 389 |
| style-src-elem | 100/100 | 46/100 | 3 188 |
| upgrade-insecure-requests | 100/100 | 100/100 | 49 894 |
| worker-src | 100/100 | 16/100 | 101 932 |
| trusted-types | 99/100 | 91/100 | 167 |
| img-src | 98/100 | 16/100 | 148 508 |
| connect-src | 97/100 | 13/100 | 144 155 |
| object-src | 96/100 | 22/100 | 147 729 |
| block-all-mixed-content | 94/100 | 94/100 | 6 137 |
| script-src-attr | 94/100 | 63/100 | 2 887 |
| webrtc | 94/100 | 94/100 | 45 |
| style-src | 90/100 | 16/100 | 138 004 |
| child-src | 88/100 | 4/100 | 99 913 |
| style-src-attr | 82/100 | 55/100 | 2 008 |
| script-src-elem | 81/100 | 19/100 | 4 915 |
| sandbox | 71/100 | 46/100 | 201 |
| fenced-frame-src | 0/100 | 64/100 | 21 |
| navigate-to | 0/100 | 92/100 | 28 |
| plugin-types | 0/100 | 94/100 | 19 |
| prefetch-src | 0/100 | 77/100 | 123 |
| referrer | 0/100 | 94/100 | 15 |
| reflected-xss | 0/100 | 94/100 | 16 |
| require-sri-for | 0/100 | 54/100 | 14 |

Chaque radar trace tous les contrôles de posture que nous mesurons, hors en-têtes d’hygiène, aussi peu de domaines les utilisent-ils. Lisez les deux extrêmes avec prudence. Un rayon proche de zéro peut signifier que le contrôle est mal configuré, ou simplement que presque personne ne le définit. Un rayon proche du bord peut signifier la même chose : chaque moyenne ne couvre que les domaines qui définissent ce contrôle, si bien qu’un contrôle rare se place souvent haut parce que la poignée qui s’en soucie le configure aussi correctement. Le vert correspond à 150 domaines, l’ambre à l’ensemble des 761 367.

Les meilleurs sites tranchent la question centrale du rapport. Une posture stricte et sûre est parfaitement constructible, et **une frange d'un site sur 5 000** l'a construite. La distance jusqu'aux autres n'est pas affaire de réglage. C'est la distance entre envoyer un en-tête et maintenir une politique entière, ce même écart qualité haute, sécurité basse suivi ici du premier au dernier graphique.

* * *

Ce rapport est produit par analyse automatisée des en-têtes et ne reflète que la configuration de chaque cible au moment de l'analyse. Il ne remplace pas un test d'intrusion, une revue de code source ou un test d'exécution, et n'affirme pas l'absence d'autres vulnérabilités. Toutes les statistiques sont des parts de population anonymisées sur les domaines que nous analysons, et aucun site n'est nommé individuellement.

## Où se situe votre site ?

Analysez votre domaine avec les mêmes contrôles que ceux qui ont produit ce rapport, puis laissez CentralCSP collecter les vrais rapports Content-Security-Policy envoyés par les navigateurs de vos visiteurs pour combler l'écart.

[Scannez votre site](https://centralcsp.com/fr/tools/csp-scanner/) [Commencer avec CentralCSP](https://app.centralcsp.com)

---

Disponible en : [en](https://centralcsp.com/en/state-of-the-web/), [fr](https://centralcsp.com/fr/state-of-the-web/)