# Hash de script (/fr/docs/web-security/reporting-api/reports/csp-hash)



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'`](/fr/docs/web-security/policies/content-security-policy/values/report-sha-keyword) 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.

<Callout type="warn" title="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.
</Callout>

## Quand le navigateur l'envoie [#quand-le-navigateur-lenvoie]

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 [#configuration]

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

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

## Exemple de payload [#exemple-de-payload]

```json
{
  "type": "csp-hash",
  "age": 12,
  "url": "https://example.com/",
  "user_agent": "Mozilla/5.0 ...",
  "body": {
    "documentURL": "https://example.com/",
    "subresourceURL": "https://example.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 [#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 [#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](/fr/docs/platform/features/script-inventory) 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é [#ce-quil-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 [#pièges]

<Callout type="info">
  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.
</Callout>

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.

## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs]

Navigateurs basés sur Chromium uniquement, où il est activé par défaut. Firefox et Safari
ne le prennent pas en charge. La forme des champs suit Chromium plutôt que le brouillon
CSP, alors traitez tout payload capturé comme spécifique à Chromium.

## Voir aussi [#voir-aussi]

* [mot-clé report-sha](/fr/docs/web-security/policies/content-security-policy/values/report-sha-keyword)
* [Content Security Policy](/fr/docs/web-security/policies/content-security-policy)
* [report integrity-violation](/fr/docs/web-security/reporting-api/reports/integrity-violation)
* [Script inventory et SBOM](/fr/docs/platform/features/script-inventory)
* [Monitoring des hash de script dans CentralCSP](/fr/docs/platform/monitoring/script-hash)
* [Header Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Le format de livraison des rapports](/fr/docs/web-security/reporting-api/concepts/report-delivery-format)

## Sources [#sources]

* [Chrome, URL and eval hashes in CSP](https://developer.chrome.com/blog/script-src-hashes)
* [W3C, Content Security Policy editor draft](https://w3c.github.io/webappsec-csp/)
* [Chrome Platform Status](https://chromestatus.com/feature/6337535507431424)