# Mot-clé report-sha256 (/fr/docs/web-security/policies/content-security-policy/values/report-sha-keyword)



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](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
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](/platform/csp-builder) de CentralCSP.

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

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

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

## Syntaxe [#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](/fr/docs/web-security/policies/content-security-policy/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 [#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.

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

## Le rapport csp-hash [#le-rapport-csp-hash]

Le navigateur livre ces rapports via la Reporting API sous le type
[`csp-hash`](/fr/docs/web-security/reporting-api/reports/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 [#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](/platform/csp-builder).

## Limites connues [#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 [#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 [#exemples]

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

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

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

## Recommandation [#recommandation]

Ajoutez `'report-sha256'` à `script-src` dans une
[politique Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only),
à côté de votre politique appliquée, pour que la collecte de hashs n'affecte
jamais ce qui s'exécute.

```http
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](/platform/supply-chain) 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 [#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.

## Voir aussi [#voir-aussi]

* [Hashs et nonces](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
* [Mots-clés](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)
* [Header Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only)
* [Directive script-src](/fr/docs/web-security/policies/content-security-policy/directives/script-src)
* [Rapport csp-hash](/fr/docs/web-security/reporting-api/reports/csp-hash)
* [Les mots-clés CSP report-sha expliqués](/fr/blog/csp-report-sha-keywords)

## Sources [#sources]

* [W3C, Content Security Policy Level 3, hash sources](https://w3c.github.io/webappsec-csp/#framework-directive-source-list)
* [MDN, Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy)
* [Chrome, Content security policy](https://developer.chrome.com/docs/privacy-security/csp)
* [Chrome Platform Status, hash reporting for scripts](https://chromestatus.com/feature/6337535507431424)
* [Chrome blog, hashes in script-src](https://developer.chrome.com/blog/script-src-hashes)