---
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 521 442 domaines. La qualité de configuration atteint 95,8 sur 100, la sécurité 28,2. Adoption des en-têtes de sécurité, de la CSP, des politiques modernes et de la Reporting API, qualité de configuration, et priorités de correction."
url: "https://next.centralcsp.com/fr/state-of-the-web/"
lang: "fr"
---

Recherche

Publié le 17 août 2026 · 521 442 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 521 442 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 95,8 sur 100 en moyenne. La sécurité, c'est-à-dire la protection réellement apportée, atteint 28,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 un demi-million de domaines c'est le cas normal.

Sécurité 28,2 /100

Qualité 95,8 /100

Global 28,0 /100

521 442

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

118 078

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

## Points clés

-   **Presque rien ne résiste à l'injection de script.** 83 domaines sur 521 442 réussissent, et 99,3 % sont exposés.
-   **Un quart du web expédie une Content-Security-Policy ; 4,4 % de ces politiques passent.** Une CSP conforme existe sur 0,97 % des domaines.
-   **Les nonces ne se sont pas imposés.** 5,4 % des politiques en utilisent un, contre 37,1 % qui autorisent encore `unsafe-inline`.
-   **Le reporting est un artefact de CDN.** 32,0 % des domaines collectent des rapports d'erreur réseau parce qu'un CDN les a activés ; 2,2 % collectent leurs propres violations CSP.
-   **Le plafond est atteignable.** Les 150 meilleurs domaines atteignent 88,6 sur 100 en moyenne, contre 28,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 tout en bas. Environ six sites sur dix se situent dans la tranche 20-40, et **86,1 % obtiennent moins de 40** au total.

L'entassement est encore plus net à l'intérieur de cette tranche. La seule plage 20-30 contient plus du tiers du web (35,4 %). Au-dessus de 60 on trouve **environ 2 % des sites**, et toute la plage 90-100 tient en 21 domaines sur 521 442.

Ce n'est pas une population en bonne santé avec une traîne en difficulté. La difficulté, c'est la population.

La gaufre ci-dessous représente tout le web en 100 carrés, teintés par tranche de note. Regardez le bloc rouge en haut : ce sont les deux tranches les plus basses, qui remplissent à elles seules 86 des 100 carrés.

0-20 29,0 % (151 414) 20-40 57,1 % (297 848) 40-60 11,8 % (61 749) 60-80 1,8 % (9 540) 80-100 0,2 % (891)

0-20 : 29,0 % des domaines. 20-40 : 57,1 % des domaines. 40-60 : 11,8 % des domaines. 60-80 : 1,8 % des domaines. 80-100 : 0,2 % des domaines.

Chaque carré vaut environ 1 % des 521 442 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.

## Comment nous avons mesuré

Chacun des 521 442 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 22,0 %**. Rien n'obligeait ces deux chiffres à concorder, et le fait qu'ils concordent est 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. **Chaque vecteur laisse 88 % des sites ou plus exposés.**

La protection complète est une erreur d'arrondi. Seuls 83 domaines passent sur l'injection de script et 97 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.

L'exception relative est le clickjacking, où 5,2 % passent, et uniquement parce que le correctif tient dans un vieil en-tête simple. Même là, presque neuf sites sur dix 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é 5,2 % Partiel 6,0 % Exposé 88,8 %

Exposition du corpus
| Protégé | 27 096 (5,2 %) |
| Partiel | 31 412 (6,0 %) |
| Exposé | 462 934 (88,8 %) |

Résistance moyenne 18/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 19 passe (5,2 %)**, et à peu près un sur neuf dispose d'une défense partielle. Les 88,8 % 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 18 sur 100 de résistance moyenne.

Exposition du corpus

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

Exposition du corpus
| Protégé | 83 (0,0 %) |
| Partiel | 3 491 (0,7 %) |
| Exposé | 517 868 (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 521 442 domaines, **83 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.

100,0 % exposés Résistance moyenne 3/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**, la résistance moyenne est de 3 sur 100, et le web est exposé à 100 % en pratique.

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

Exposition du corpus

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

Exposition du corpus
| Protégé | 97 (0,0 %) |
| Partiel | 7 324 (1,4 %) |
| Exposé | 514 021 (98,6 %) |

Résistance moyenne 45/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.

**97 domaines sur 521 442 passent** et 98,6 % sont exposés. Les défenses partielles viennent des 1,4 % de sites qui fixent certains canaux mais pas tous.

Ce vecteur affiche la résistance moyenne la plus élevée des quatre, 45 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 à 68,4 %, 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` à 42,2 %, `X-Frame-Options` à 39,3 %, `Strict-Transport-Security` à 38,8 %. Les en-têtes cross-origin, qui demandent une vraie réflexion, tombent à 1,4 % 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` comme `Cross-Origin-Resource-Policy` passent chez la totalité des leurs.

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 84,5 % de ses émetteurs, `Cache-Control` chez 85,6 %.

Un en-tête rompt le schéma. Près de deux sites sur cinq envoient `Strict-Transport-Security`, mais **moins de la moitié l'envoient correctement** : 42,3 % des émetteurs HSTS passent, les autres livrent un `max-age` trop court ou sautent `includeSubDomains` et `preload`.

Cet écart résume toute la section. Rapporté au corpus entier, un HSTS pleinement correct ne touche qu'**un site sur six (16,4 %)**. 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.

En-têtes de réponse protecteurs

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

| En-tête | Adoption | Réussite Partiel Échec |
| --- | --- | --- |
| Cache-Control | 68,4 % | 85,6 / 0,0 / 14,4 |
| X-Content-Type-Options | 42,2 % | 99,9 / 0,0 / 0,1 |
| X-Frame-Options | 39,3 % | 100,0 / 0,0 / 0,0 |
| Strict-Transport-Security | 38,8 % | 42,3 / 32,2 / 25,4 |
| Referrer-Policy | 27,1 % | 84,5 / 0,0 / 15,5 |
| Cross-Origin-Resource-Policy | 1,4 % | 100,0 / 0,0 / 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. | 21,2 % |
| Expect-CT | Reporting Certificate Transparency, devenu redondant depuis que CT est obligatoire. | 1,2 % |
| Feature-Policy | Renommé et remplacé par Permissions-Policy. | 0,8 % |
| 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, **plus d'un cinquième du web envoie encore cet en-tête** (21,2 %, 110 371 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,6 %, 101 139 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.

21,2 %

envoient encore X-XSS-Protection

110 371 domaines sur 521 442 conservent un en-tête que tous les navigateurs actuels ont retiré.

91,6 %

d'entre eux utilisent la valeur dangereuse

101 139 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,1 %), et plus de la moitié d'entre eux impriment aussi la version (54,9 % des sites concernés), ce qui laisse environ un site sur cinq exposer la version exacte qu'il exécute (21,5 % 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,1 %

nomment leur technologie dans un en-tête

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

21,5 %

exposent aussi la version exacte

111 896 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 492 692 cookies du corpus, environ la moitié porte chaque attribut protecteur : `Secure` sur 55,0 %, `HttpOnly` sur 49,5 %, `SameSite` sur 46,8 %. **Moins de la moitié déclarent `SameSite`.**

La valeur de `SameSite` est le retournement le plus net. Parmi les cookies qui la posent, la plupart choisissent `None`, la valeur qui renonce à la protection cross-site. **À 49,7 % elle est majoritaire relative**, juste devant `Lax` à 44,9 % et très loin devant `Strict` à 5,3 %.

Le choix de durcissement le plus fréquent est donc le plus faible. Rapporté à tous les cookies du corpus, `None` concerne environ un cookie sur quatre (23,2 %), tandis que `Strict` reste une erreur d'arrondi.

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 492 692 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. | 55,0 % | 271 223 |
| HttpOnly | Invisible pour JavaScript, donc illisible par un script injecté. | 49,5 % | 243 865 |
| SameSite | Limite les cas où le cookie accompagne une requête cross-site. | 46,8 % | 230 548 |

Valeur SameSite, quand elle est posée

Aucun 49,7 % Lax 45,0 % Strict 5,3 %

Valeur SameSite, quand elle est posée
| Aucun | 114 526 (49,7 %) |
| Lax | 103 616 (45,0 %) |
| Strict | 12 285 (5,3 %) |

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 quart des sites 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 22,0 % Sans CSP 78,0 %

Adoption
| Expédie une CSP | 114 974 (22,0 %) |
| Sans CSP | 406 468 (78,0 %) |

Résultat de sécurité

Réussite 4,4 % Partiel 4,6 % Échec 91,0 %

Résultat de sécurité
| Réussite | 5 049 (4,4 %) |
| Partiel | 5 250 (4,6 %) |
| Échec | 104 675 (91,0 %) |

Mode de livraison

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

Mode de livraison
| En-tête | 113 398 (96,0 %) |
| Les deux | 1 576 (1,3 %) |
| Balise meta | 3 104 (2,6 %) |

Mode

Appliqué 90,8 % Les deux 2,6 % Rapport uniquement 6,6 %

Mode
| Appliqué | 104 416 (90,8 %) |
| Les deux | 2 951 (2,6 %) |
| Rapport uniquement | 7 607 (6,6 %) |

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. **22,0 % du web expédie une CSP** (114 974 domaines sur 521 442), 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,0 % échouent** (104 675 sites) et seulement 4,4 % passent (5 049 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 (90,8 %), et **96,0 % arrivent dans un en-tête**, seuls 2,6 % 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,97 % des domaines**. Moins d'un site sur cent dispose du contrôle qui contiendrait l'attaque côté client la plus courante.

### 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,8 % des sites à CSP et passe dans 76,8 % 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 39,4 % des sites à CSP et **échoue dans 89,4 % des cas** (41 560 usages sur 46 469).

Le schéma se poursuit dans tout le tableau. Les directives qui contraignent scripts et styles échouent le plus (`style-src` passe dans 8,2 % des cas, `script-src-elem` dans 6,4 %), tandis que les structurelles passent facilement : `base-uri` passe à 85,5 %, 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 276 sites à CSP, `trusted-types` sur 144.

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 118 078 domaines livrant une CSP qui posent chaque directive, et note de ces usages.

| Directive | Utilisé | Réussite Partiel Échec |
| --- | --- | --- |
| frame-ancestors | 54,8 % | 76,8 / 12,4 / 10,8 |
| default-src | 40,1 % | 55,4 / 1,7 / 42,8 |
| script-src | 39,4 % | 10,6 / 0,0 / 89,4 |
| img-src | 36,8 % | 17,1 / 1,8 / 81,1 |
| style-src | 33,6 % | 8,2 / 47,2 / 44,5 |
| font-src | 33,4 % | 71,9 / 0,5 / 27,6 |
| upgrade-insecure-requests | 33,3 % | 100,0 / 0,0 / 0,0 |
| connect-src | 33,0 % | 20,7 / 0,0 / 79,3 |
| frame-src | 30,3 % | 26,0 / 13,2 / 60,9 |
| object-src | 27,3 % | 71,0 / 0,0 / 29,0 |
| base-uri | 24,2 % | 85,5 / 0,0 / 14,5 |
| media-src | 17,8 % | 61,7 / 1,0 / 37,3 |
| form-action | 17,6 % | 64,6 / 3,2 / 32,2 |
| worker-src | 14,7 % | 66,7 / 0,0 / 33,3 |
| child-src | 8,2 % | 17,7 / 28,8 / 53,5 |
| report-uri | 8,1 % | 99,9 / 0,0 / 0,1 |
| manifest-src | 6,9 % | 92,8 / 0,1 / 7,2 |
| block-all-mixed-content | 4,5 % | 100,0 / 0,0 / 0,0 |
| script-src-elem | 3,5 % | 6,4 / 0,0 / 93,6 |
| report-to | 3,2 % | 99,7 / 0,0 / 0,3 |
| style-src-elem | 2,3 % | 10,0 / 45,3 / 44,7 |
| script-src-attr | 2,0 % | 47,6 / 0,0 / 52,4 |
| style-src-attr | 1,4 % | 9,3 / 85,4 / 5,3 |
| require-trusted-types-for | 0,2 % | 100,0 / 0,0 / 0,0 |
| sandbox | 0,2 % | 7,4 / 0,0 / 92,6 |
| prefetch-src | 0,1 % | 73,5 / 5,1 / 21,4 |
| trusted-types | 0,1 % | 92,4 / 0,0 / 7,6 |
| fenced-frame-src | 0,0 % | 52,6 / 10,5 / 36,8 |
| navigate-to | 0,0 % | 96,8 / 0,0 / 3,2 |
| plugin-types | 0,0 % | 100,0 / 0,0 / 0,0 |
| referrer | 0,0 % | 100,0 / 0,0 / 0,0 |
| reflected-xss | 0,0 % | 100,0 / 0,0 / 0,0 |
| require-sri-for | 0,0 % | 0,0 / 100,0 / 0,0 |
| webrtc | 0,0 % | 100,0 / 0,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 37,1 % des sites à CSP et `unsafe-eval` sur 32,6 %. Les nonces, le mécanisme de durcissement phare, atteignent **5,4 %**. 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,7 % des sites à CSP** (3 186 politiques). Trusted Types, la meilleure défense que la plateforme offre contre l'injection dans le DOM, n'est imposé que sur 275.

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,5 %) ou un script gadget connu (20,9 %), 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 118 078 domaines livrant une CSP.

| Mécanisme de durcissement | Domaines | Durcissement |
| --- | --- | --- |
| upgrade-insecure-requests | 39,3k | 33,3 % |
| Nonces | 6,3k | 5,4 % |
| strict-dynamic | 3,2k | 2,7 % |
| Hashs | 2,2k | 1,9 % |
| Trusted Types (imposé) | 275 | 0,2 % |
| Trusted Types (déclaré) | 144 | 0,1 % |

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

Mécanisme d'affaiblissement

Part des 118 078 domaines livrant une CSP.

| Mécanisme d'affaiblissement | Domaines | Affaiblissement |
| --- | --- | --- |
| unsafe-inline | 43,8k | 37,1 % |
| unsafe-eval | 38,5k | 32,6 % |
| Endpoint JSONP | 26,6k | 22,5 % |
| Script gadget | 24,7k | 20,9 % |
| Joker de sous-domaine | 22,5k | 19,1 % |
| Source de schéma | 21,1k | 17,9 % |
| Hôte mutualisé | 13,3k | 11,3 % |
| Joker complet \* | 4,4k | 3,7 % |
| wasm-unsafe-eval | 1,5k | 1,3 % |
| unsafe-hashes | 740 | 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 12,3 % des sites à CSP**, et c'est le maintien d'une directive dépréciée recopiée d'un vieux modèle.

En dessous, la liste tombe à un seul chiffre : une valeur source en double (8,2 %), un mot-clé utilisé dans une directive qui l'ignore (6,1 %), une source déjà couverte par une plus large (5,9 %). 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 325 sépare ses directives par des virgules au lieu de points-virgules, ce qui ne déclenche aucune erreur qu'un développeur puisse voir. Cela réduit silencieusement la politique à du non-sens.

**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 118 078 domaines livrant une CSP touchés par chaque erreur.

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

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 **32,0 % des domaines**, devant Content-Security-Policy à 22,0 %, 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. Permissions-Policy touche 9,7 % et COOP 8,7 %, environ un site sur onze. COEP, la seconde moitié de l'isolation cross-origin, atteint **0,8 % 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 onze 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 % (584 domaines), tandis qu'Integrity-Policy et Connection-Allowlist tiennent en une poignée, **10 domaines et 3**. 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 521 442 domaines notés qui déploient chaque politique.

| Politique | Déployé | Appliqué Les deux Rapport uniquement |
| --- | --- | --- |
| Network Error Logging | 32,0 % | 100,0 / 0,0 / 0,0 |
| Content-Security-Policy | 22,0 % | 90,8 / 2,6 / 6,6 |
| Permissions-Policy | 9,7 % | 99,9 / 0,0 / 0,0 |
| Cross-Origin-Opener-Policy | 8,7 % | 96,7 / 3,0 / 0,3 |
| Cross-Origin-Embedder-Policy | 0,8 % | 63,9 / 32,7 / 3,4 |
| Document-Policy | 0,1 % | 99,3 / 0,2 / 0,5 |
| Connection-Allowlist | 0,0 % | 33,3 / 0,0 / 66,7 |
| Integrity-Policy | 0,0 % | 50,0 / 0,0 / 50,0 |

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,0 % des politiques évaluées** et passe sur 4,4 %. Toute autre politique largement déployée passe presque à chaque fois qu'elle est posée : Permissions-Policy à 100 %, NEL à 100 % en pratique, COOP à 94,8 %.

COEP est le cas intermédiaire intéressant. Elle ne passe que chez 15,6 % de ses déployeurs, les 84,4 % 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 | 4.4% | 4.6% | 91% |
| NEL | 100% | 0% | 0% |
| Permissions | 100% | 0% | 0% |
| COOP | 94.8% | 5.2% | 0% |
| COEP | 15.6% | 84.4% | 0% |
| Document | 100% | 0% | 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 166 629 domaines ; tous les autres types de rapport qu'un site choisirait vraiment totalisent **17 494 domaines** à eux tous.

Le rapport qui compte le plus est le plus rare des courants. **2,2 % du corpus** collecte ses propres violations de Content-Security-Policy : 11 526 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 596 domaines qui câblent le reporting COOP, **89,8 % l'ont cassé**, et le reporting COEP est cassé sur 95,3 % des 1 523 qui essaient.

Le reporting CSP se porte mieux : 97,3 % 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,3 % de fonctionnel pour la CSP et 4,7 % 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 521 442 domaines ; les colonnes fonctionnel et cassé découpent le total de la ligne.

| Type de rapport | Configuré pour remonter | Fonctionnel Cassé |
| --- | --- | --- |
| Erreur réseau | 32,0 % | 100,0 / 0,0 |
| Violation CSP | 2,2 % | 97,3 / 2,7 |
| Rapport COOP | 0,3 % | 10,2 / 89,8 |
| Violation COEP | 0,3 % | 4,7 / 95,3 |
| Plantage | 0,2 % | 98,9 / 1,1 |
| Dépréciation | 0,2 % | 98,9 / 1,1 |
| Intervention | 0,2 % | 98,9 / 1,1 |
| Violation Permissions-Policy | 0,1 % | 99,5 / 0,5 |
| Rapport de hash de script CSP | 0,0 % | 94,4 / 5,6 |
| Violation Document-Policy | 0,0 % | 71,4 / 28,6 |
| Violation d'intégrité | 0,0 % | 100,0 / 0,0 |
| 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, **97,5 % utilisent encore `Report-To` déprécié**, et 2,5 % 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 32,3 % du corpus, 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 : 4 281 sites, 0,8 % du corpus, environ un site sur 122.

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

Reporting-Endpoints 2,5 % Report-To (déprécié) 97,5 %

Domaines déclarant un en-tête de reporting
| Reporting-Endpoints | 4 281 (2,5 %) |
| Report-To (déprécié) | 168 672 (97,5 %) |

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 ?

149 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,4 %) 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 sur six** laisse encore `object-src` charger des plugins (18,0 %) ou laisse `base-uri` ouvert (18,0 %), et 17,3 % laissent `connect-src` exfiltrer librement.

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 22 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 149 constats du catalogue, pondérés par sévérité et par portée, sur l'ensemble des 521 442 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é | 517,4k | 99,2 % |
| À faire maintenant | Ajoutez un en-tête Integrity-Policy pour exiger le SRI sur les scripts. | Élevé | 515,6k | 98,9 % |
| À faire maintenant | Définissez connect-src à 'self' et à vos hôtes connus. | Élevé | 513,2k | 98,4 % |
| Corriger votre CSP | Définissez object-src 'none'. | Élevé | 93,8k | 18,0 % |
| Corriger votre CSP | Définissez base-uri 'none' (ou 'self'). | Élevé | 93,7k | 18,0 % |
| Corriger votre CSP | Restreignez connect-src à 'self' et à vos hôtes d'API/analytics. | Élevé | 90,5k | 17,3 % |
| Corriger votre CSP | Retirez 'unsafe-inline' ; utilisez un nonce avec 'strict-dynamic'. | Élevé | 42,8k | 8,2 % |
| Corriger votre CSP | Retirez 'unsafe-eval' de la directive. | Élevé | 36,8k | 7,1 % |
| Corriger votre CSP | Retirez le schéma dangereux de la directive. | Élevé | 26k | 5,0 % |
| Corriger votre CSP | Retirez l'hôte JSONP de la directive. | Élevé | 25,9k | 5,0 % |
| Corriger votre CSP | Retirez l'hôte de script gadget de la directive. | Élevé | 24,2k | 4,6 % |
| Corriger votre CSP | Remplacez l'hôte mutualisé par un hôte dédié que vous contrôlez. | Élevé | 13,3k | 2,5 % |
| Corriger votre CSP | Retirez la source de schéma de la directive. | Élevé | 8,1k | 1,5 % |
| Corriger votre CSP | Déplacez la CSP vers l'en-tête appliqué. | Élevé | 7,6k | 1,5 % |
| Corriger votre CSP | Remplacez default-src \* par 'self'/'none' et définissez les sources par directive. | Élevé | 3,6k | 0,7 % |
| Corriger votre CSP | Remplacez le joker de la directive par une politique à nonce. | Élevé | 2,7k | 0,5 % |
| Corriger votre CSP | Générez un nonce neuf à chaque réponse. | Élevé | 1,2k | 0,2 % |
| Recommandé | Ajoutez un en-tête Permissions-Policy désactivant les fonctions inutilisées. | Moyen | 470,6k | 90,3 % |
| Corriger votre CSP | Ajoutez une CSP stricte basée sur un nonce. | Moyen | 403,4k | 77,4 % |
| Recommandé | Ajoutez un en-tête NEL avec un groupe report-to. | Moyen | 354,8k | 68,0 % |

149 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 **88,6 sur 100** en moyenne ; l'ensemble des 521 442 atteint 28,0. Soit un écart de 60,6 points, plus de trois 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 : **96,2 pour la cohorte des meilleurs contre 95,8 pour tous les autres**, moins d'un demi-point de différence.

En sécurité, ce ne sont plus les mêmes webs. La cohorte des meilleurs atteint **89,0 sur 100** contre 28,2 pour la moyenne du corpus, et ce seul axe porte la totalité des 60,6 points d'écart.

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 88,6 /100

Moyenne du corpus 28,0 /100

L'écart +60,6 pts

Les 150 domaines les mieux configurés face à l'ensemble des 521 442, 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 521 442 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 3 400**. 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 5 pour la moyenne, un rapport de vingt et le plus large de tous. La résistance aux attaques donne 80 contre 18, et les politiques 59 contre 13, soit **quatre à cinq 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 paraît honorable, 74 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 **9 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 aussi signifier que le contrôle est simplement absent, et là où la cohorte des meilleurs est à zéro sur une directive dépréciée, l'abandonner est le bon geste.

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 |
| --- | --- | --- |
| Cross-Origin-Resource-Policy | 100/100 | 100/100 |
| Expect-CT | 100/100 | 100/100 |
| Feature-Policy | 100/100 | 100/100 |
| Public-Key-Pins | 100/100 | 100/100 |
| X-Content-Type-Options | 100/100 | 42/100 |
| Referrer-Policy | 100/100 | 24/100 |
| Strict-Transport-Security | 99/100 | 24/100 |
| Cache-Control | 98/100 | 89/100 |
| X-XSS-Protection | 82/100 | 89/100 |

Résistance aux attaques

Résistance aux attaques
| Résistance aux attaques | Meilleurs sites | Moyenne du corpus |
| --- | --- | --- |
| Clickjacking | 98/100 | 18/100 |
| Exfiltration de données | 88/100 | 45/100 |
| Injection de script | 82/100 | 3/100 |
| Chaîne d'appro. | 50/100 | 3/100 |

Politiques Reporting-API

Politiques Reporting-API
| Politiques Reporting-API | Meilleurs sites | Moyenne du corpus |
| --- | --- | --- |
| Document-Policy | 100/100 | 100/100 |
| Integrity-Policy | 100/100 | 66/100 |
| Permissions-Policy | 99/100 | 10/100 |
| Cross-Origin-Opener-Policy | 67/100 | 8/100 |
| Content-Security-Policy | 52/100 | 29/100 |
| Cross-Origin-Embedder-Policy | 45/100 | 0/100 |
| Network Error Logging | 29/100 | 32/100 |
| Connection-Allowlist | 0/100 | 100/100 |

Configuration Reporting-API

Configuration Reporting-API
| Configuration Reporting-API | Meilleurs sites | Moyenne du corpus |
| --- | --- | --- |
| Violation CSP | 41/100 | 2/100 |
| Erreur réseau | 27/100 | 32/100 |
| Plantage | 9/100 | 0/100 |
| Dépréciation | 9/100 | 0/100 |
| Intervention | 9/100 | 0/100 |
| Violation Permissions-Policy | 9/100 | 0/100 |
| Violation COEP | 3/100 | 0/100 |
| Rapport COOP | 3/100 | 0/100 |
| Connection-Allowlist | 1/100 | 0/100 |
| Rapport de hash de script CSP | 1/100 | 0/100 |
| Violation Document-Policy | 1/100 | 0/100 |
| Violation d'intégrité | 1/100 | 0/100 |

Content Security Policy

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

Content Security Policy
| Content Security Policy | Meilleurs sites | Moyenne du corpus |
| --- | --- | --- |
| default-src | 100/100 | 24/100 |
| font-src | 100/100 | 27/100 |
| form-action | 100/100 | 12/100 |
| frame-ancestors | 100/100 | 84/100 |
| manifest-src | 100/100 | 10/100 |
| report-to | 100/100 | 100/100 |
| require-trusted-types-for | 100/100 | 100/100 |
| upgrade-insecure-requests | 100/100 | 100/100 |
| worker-src | 100/100 | 14/100 |
| media-src | 99/100 | 15/100 |
| script-src | 99/100 | 6/100 |
| trusted-types | 99/100 | 92/100 |
| base-uri | 98/100 | 21/100 |
| block-all-mixed-content | 97/100 | 97/100 |
| child-src | 97/100 | 4/100 |
| frame-src | 97/100 | 13/100 |
| report-uri | 97/100 | 97/100 |
| webrtc | 97/100 | 97/100 |
| img-src | 96/100 | 12/100 |
| object-src | 96/100 | 20/100 |
| connect-src | 95/100 | 10/100 |
| style-src-elem | 91/100 | 35/100 |
| script-src-attr | 87/100 | 53/100 |
| style-src | 83/100 | 12/100 |
| style-src-attr | 81/100 | 48/100 |
| script-src-elem | 78/100 | 10/100 |
| sandbox | 74/100 | 30/100 |
| fenced-frame-src | 0/100 | 58/100 |
| navigate-to | 0/100 | 94/100 |
| plugin-types | 0/100 | 97/100 |
| prefetch-src | 0/100 | 75/100 |
| referrer | 0/100 | 97/100 |
| reflected-xss | 0/100 | 97/100 |
| require-sri-for | 0/100 | 45/100 |

Chaque radar trace tous les contrôles de posture sauf les en-têtes d'hygiène, quel que soit leur statut. Un contrôle que peu de domaines posent apparaît quand même à sa moyenne (souvent basse), pour que l'écart entre la cohorte des meilleurs et la moyenne reste comparable. Une branche proche de zéro ne signifie pas toujours que le contrôle est mal configuré : elle peut aussi signifier que les domaines ne le posent tout simplement pas. Le vert représente 150 domaines, l'ambre l'ensemble des 521 442.

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 3 400** 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://next.centralcsp.com/fr/tools/csp-scanner/) [Commencer avec CentralCSP](https://app.next.centralcsp.com)

---

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