Mots-clés CSP report-sha256, report-sha384 et report-sha512

Les mots-clés de hash report-only report-sha256, report-sha384 et report-sha512 qui alimentent le reporting de hash de script du navigateur et le SBOM.

Les mots-clés 'report-sha256', 'report-sha384' et 'report-sha512' demandent au navigateur de calculer et de signaler un hash de chaque script inline et externe qu'il charge, sans rien bloquer. Contrairement à une source de hash classique, qui autorise un script dont vous connaissez déjà l'empreinte, ces mots-clés report-only inversent le sens : le navigateur vous dit ce qu'il a exécuté en émettant un rapport csp-hash. C'est le mécanisme derrière l'inventaire de scripts et le SBOM de CentralCSP.

Chromium uniquement, en cours de standardisation

Ces mots-clés sont livrés en version stable dans Chromium, activés par défaut, et ils figurent dans la grammaire du brouillon d'éditeur CSP3. Firefox et Safari ne les ont pas implémentés ni annoncé leur intention de le faire, donc l'inventaire produit ne couvre que les utilisateurs Chromium. Voir la section Prise en charge par les navigateurs ci-dessous.

Une politique de collecte report-only, telle que vous la déploieriez :

Content-Security-Policy-Report-Only:
    script-src 'report-sha256';
    report-to csp-endpoint

Syntaxe

Chaque mot-clé est un jeton entre apostrophes placé dans une directive de script, en général script-src, et il est prévu pour le header Report-Only afin de ne jamais affecter l'application de la politique.

Le nombre désigne l'algorithme d'empreinte : 'report-sha256', 'report-sha384' ou 'report-sha512'. Le navigateur hache chaque script avec cet algorithme et inclut le résultat dans un rapport.

Valeur	Statut	Description
`'report-sha256'`	🧪 Expérimental	Signale l'empreinte SHA-256 de chaque script. Chromium uniquement.
`'report-sha384'`	🧪 Expérimental	Le même reporting avec des empreintes SHA-384. Chromium uniquement.
`'report-sha512'`	🧪 Expérimental	Le même reporting avec des empreintes SHA-512. Chromium uniquement.

Ce que cela fait

Lorsqu'une directive contient un mot-clé 'report-sha...', le navigateur calcule l'empreinte de chaque script qu'il charge sous cette directive et envoie un rapport csp-hash pour chacun vers l'endpoint configuré. Cela ne change pas si le script s'exécute ou non ; la collecte est le seul effet. Au fil du temps, le flux de rapports décrit chaque script qui s'est réellement exécuté sur de vrais chargements de page, inline et externes, y compris ceux ajoutés à l'exécution par des tags tiers.

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Le rapport csp-hash

Le navigateur livre ces rapports via la Reporting API sous le type csp-hash. Chaque rapport transporte le hash du script et assez de contexte pour identifier la ressource. Le mot-clé et le rapport figurent dans le brouillon d'éditeur CSP3, mais aucun second moteur ne les a encore implémentés, donc les détails pourraient encore évoluer avant un accord multi-éditeurs.

C'est ce qui alimente un inventaire de scripts : en confrontant les hashs signalés à des bibliothèques connues, CentralCSP construit un software bill of materials (SBOM) pour chaque page, détecte la technologie et la version derrière chaque script, et signale les CVE connues, sans que vous mainteniez une allowlist de hashs à la main.

Contre quoi cela protège

En lui-même, le mot-clé n'applique rien ; sa valeur est la visibilité. Savoir exactement quels scripts s'exécutent sur une page, en particulier les scripts tiers et injectés dynamiquement qu'une revue manuelle rate, est la matière première pour détecter un script inattendu ou altéré, ce qui est le problème de détection de changement côté client derrière les exigences 6.4.3 et 11.6.1 de PCI DSS v4. CentralCSP utilise ce signal pour la surveillance et l'alerting de scripts.

Limites connues

C'est une aide au reporting, pas un contrôle : il ne peut pas bloquer un script malveillant, seulement signaler qu'un script s'est exécuté. Parce qu'il est propre à Chromium, l'inventaire produit reflète les utilisateurs Chromium ; les visiteurs Firefox et Safari ne génèrent aucun rapport csp-hash. Associez-le à une politique appliquée (nonces, hashs, 'strict-dynamic') pour une protection réelle.

Risques

Le volume de reporting peut être élevé sur des pages riches en scripts, puisque chaque chargement de script produit un rapport ; échantillonnez ou agrégez côté endpoint plutôt que de stocker chaque rapport brut. Ne confondez pas couverture de reporting et application : une page peut être entièrement inventoriée et laisser quand même passer une injection inline si la politique appliquée est faible.

Exemples

Collecter les hashs de script en mode report-only pendant qu'une politique appliquée tourne séparément :

Content-Security-Policy: script-src 'self' 'nonce-r4nd0m' 'strict-dynamic'

Content-Security-Policy-Report-Only:
    script-src 'report-sha256';
    report-to csp-endpoint

Recommandation

Ajoutez 'report-sha256' à script-src dans une politique Report-Only, à côté de votre politique appliquée, pour que la collecte de hashs n'affecte jamais ce qui s'exécute.

Content-Security-Policy-Report-Only:
    script-src 'report-sha256';
    report-to csp-endpoint

Le flux de rapports vous donne un inventaire continu de chaque script qui s'exécute réellement sur de vrais chargements de page, ce dont l'inventaire de scripts et le SBOM de CentralCSP est construit. Cela ne coûte rien en application et fonctionne dès aujourd'hui pour votre trafic Chromium.

Prise en charge par les navigateurs

Stable dans les navigateurs basés sur Chromium (Chrome, Edge), activé par défaut, sur desktop, Android et WebView. Ce n'est pas un origin trial : un origin trial distinct couvre une fonctionnalité différente, les hashs d'URL et d'eval dans script-src. Firefox et Safari n'ont pas implémenté les mots-clés ni annoncé leur prise en charge. Les mots-clés figurent dans la grammaire du brouillon d'éditeur CSP3, donc ils sont sur une trajectoire de standardisation mais ne sont pas encore un standard multi-éditeurs.

Mot-clé report-sha256