Le report csp-hash, le hash de script dans CSP

Le report csp-hash envoie un hash de chaque script chargé par la page, la base pour un inventaire de scripts côté navigateur.

Un report csp-hash transporte le hash d'un script (ou d'une autre sous-ressource) que la page a chargé. Contrairement à un report de violation, il ne s'agit pas d'un blocage : vous l'activez avec une source expression 'report-sha256' et le navigateur reporte un hash pour chaque ressource correspondante. Ce flux est ce qui vous permet de construire un inventaire des scripts réellement exécutés dans le navigateur, associés à une bibliothèque, une version et des CVE connues.

Chromium uniquement

Le reporting de hash de script est activé par défaut dans Chromium, donc il fonctionne sans essai d'origine, mais il est propre à Chromium : Firefox et Safari ne l'envoient pas. La casse des champs diffère aussi du brouillon CSP (voir Pièges), alors traitez le payload comme spécifique à Chromium. Voir Prise en charge par les navigateurs ci-dessous.

Quand le navigateur l'envoie

Quand une directive de type script porte 'report-sha256' (ou 'report-sha384' / 'report-sha512'), le navigateur émet un report csp-hash pour chaque ressource correspondante qu'il charge, et affiche aussi le hash dans la console DevTools. Il reporte au lieu de bloquer, donc il n'affecte pas ce qui s'exécute. Les reports de hash ne sont pas exposés à ReportingObserver ; ils ne partent que vers l'endpoint.

Configuration

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

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

Exemple de payload

{
  "type": "csp-hash",
  "age": 12,
  "url": "https://api-next.centralcsp.com/",
  "user_agent": "Mozilla/5.0 ...",
  "body": {
    "documentURL": "https://api-next.centralcsp.com/",
    "subresourceURL": "https://api-next.centralcsp.com/main.js",
    "hash": "sha256-85738f8f9a7f1b04b5329c590ebcb9e425925b6c0d...",
    "type": "subresource",
    "destination": "script"
  }
}

Chaque body de report csp-hash porte ces champs à l'intérieur de l'enveloppe de report partagée.

Référence des champs

Champ	Signification
`documentURL`	La page sur laquelle le script s'est chargé.
`subresourceURL`	L'URL du script ou de la ressource chargée.
`hash`	Le hash sous la forme `<alg>-<base64>`, par exemple `sha256-...`.
`type`	La catégorie de hash (par exemple `subresource`).
`destination`	La destination de la requête, par exemple `script`.

Comment le recevoir

Déclarez un endpoint et ajoutez 'report-sha256' à script-src ; gardez la politique en Report-Only pour qu'elle ne bloque jamais. C'est exactement le mécanisme derrière le script inventory et le SBOM de CentralCSP, qui associe chaque hash reporté à une technologie, une version et des CVE connues, sans snippet ni extension de navigateur.

Ce qu'il vous apprend sur la sécurité

Un hash de script que vous n'avez pas déployé est un signal de supply-chain : un asset de CDN altéré, un script de formjacking ou de Magecart injecté, ou un tiers inattendu. Le reporting continu des hash, couplé à des alertes sur les hash nouveaux ou modifiés, est ce qui vous permet de détecter ce changement au moment où il atteint un vrai navigateur, plutôt que lors d'une revue post-incident.

Pièges

La casse des champs n'est pas figée : Chromium émet du camelCase (documentURL, subresourceURL) tandis que l'exemple du brouillon de l'éditeur CSP utilise du snake_case (document_url, subresource_url). Vérifiez sur une capture réelle.

Une conception antérieure utilisait un mot-clé 'report-hashes' ; le mot-clé livré est 'report-sha256' (et les variantes sha384/sha512). Le mot-clé et la forme du report évoluent encore dans le brouillon CSP, alors attendez-vous à ce qu'ils changent.

Hash de script

Quand le navigateur l'envoie

Configuration

Exemple de payload

Référence des champs

Comment le recevoir

Ce qu'il vous apprend sur la sécurité

Pièges

Prise en charge par les navigateurs

Voir aussi

Sources

On this page