# Comment générer un hash Subresource Integrity (SRI) (/fr/blog/generate-sri-hash)



Subresource Integrity (SRI) est l'attribut `integrity` qui demande au navigateur de comparer les octets d'un fichier externe au hash que vous fournissez, et de bloquer le fichier s'il ne correspond pas. Il vous faut donc deux choses : le hash, et le bon attribut sur la balise.

Générez le hash avec le [générateur SRI](/tools/sri-hash) : collez le fichier ou l'URL et il renvoie les valeurs SHA-256, SHA-384 et SHA-512 prêtes à coller. La valeur est le digest en base64 des octets bruts du fichier. Préfixez-la avec l'algorithme et placez-la sur la balise, avec `crossorigin` pour un fichier cross-origin :

```html
<script
  src="https://cdn.example.com/script.js"
  integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
  crossorigin="anonymous"></script>
```

Vous découvrez le mécanisme lui-même ? [Subresource Integrity (SRI) expliqué](/fr/blog/subresource-integrity-sri) couvre ce que c'est et ce contre quoi il protège. Le reste de cet article donne le mode d'emploi et les pièges qui le cassent en silence.

## Choisissez l'algorithme [#choisissez-lalgorithme]

Le SRI accepte `sha256`, `sha384` et `sha512`. Préférez `sha384` ou `sha512`. Le digest est calculé sur les octets bruts du fichier puis encodé en base64 : d'un algorithme à l'autre, seules la force et la longueur de la valeur changent.

Si vous listez plusieurs hashes dans la valeur `integrity`, le navigateur ne prend pas le premier. Il retient l'algorithme le plus fort présent. Avec un `sha256` à côté d'un `sha384`, seul le hash `sha384` est vérifié : lister une valeur plus faible à côté d'une plus forte n'affaiblit donc jamais le contrôle. Le [générateur SRI](/tools/sri-hash) renvoie les trois valeurs, vous pouvez donc coller celle que vous voulez.

## Associez-le à crossorigin [#associez-le-à-crossorigin]

Un `<script>` ou `<link>` cross-origin qui porte `integrity` mais pas `crossorigin="anonymous"` ne se charge jamais. C'est l'erreur SRI la plus fréquente.

Sans `crossorigin`, le navigateur récupère le fichier en mode `no-cors` et obtient une réponse opaque qu'il ne sait pas lire : il ne peut donc pas comparer les octets à votre hash, et il refuse d'exécuter le fichier. L'attribut fait passer la requête en [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS), et le navigateur peut alors lire la réponse et la vérifier.

```html
<link
  rel="stylesheet"
  href="https://cdn.example.com/styles.css"
  integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
  crossorigin="anonymous">
```

Les fichiers same-origin sont déjà lisibles, ils sont donc vérifiés sans `crossorigin`. L'attribut n'est exigé qu'en cross-origin.

## Vérifiez que ça marche [#vérifiez-que-ça-marche]

Chargez la page et surveillez le fichier. Un hash correct se charge sans bruit. Un hash faux, ou un `crossorigin` manquant sur un fichier cross-origin, fait échouer le chargement et inscrit une erreur d'intégrité dans la console du navigateur.

Pour vérifier qu'une non-correspondance est bien détectée, changez un caractère dans la valeur `integrity` et rechargez : le script doit être bloqué et la console doit signaler que la ressource n'a pas passé son contrôle d'intégrité. Remettez la valeur correcte une fois le blocage constaté.

## Gardez les hashes à jour quand les fichiers changent [#gardez-les-hashes-à-jour-quand-les-fichiers-changent]

Le SRI ne se met pas à jour tout seul. Le hash est lié aux octets exacts du fichier, il faut donc le régénérer chaque fois que le contenu du fichier change. C'est le comportement attendu : un fichier modifié avec un ancien hash est traité comme une falsification et bloqué.

C'est pourquoi une URL de CDN « latest » ou auto-minifiante casse le SRI : les octets peuvent changer sous vos pieds sans prévenir, et le prochain déploiement de leur côté bloque votre page. Épinglez une URL immuable et versionnée (un chemin de version précis, pas une étiquette mouvante) pour que le fichier que vous avez hashé reste celui que vous recevez.

C'est aussi cette charge de maintenance qui pousse les équipes à suivre les scripts tiers qu'elles déploient. À partir des rapports de hash CSP, CentralCSP construit un [inventaire de scripts](/platform/supply-chain) de tout ce qui tourne sur vos pages, pour que le changement d'un fichier tiers vous saute aux yeux au lieu de vous arriver par un chargement bloqué.

## Faites-le avec les outils de build [#faites-le-avec-les-outils-de-build]

Générer les hashes à la main devient vite ingérable au-delà de quelques fichiers. La plupart des bundlers savent émettre les attributs `integrity` automatiquement pendant le build, vous pouvez donc [l'automatiser avec Webpack ou Vite](/fr/blog/sri-webpack-vite) :

* Webpack : [webpack-subresource-integrity](https://github.com/waysact/webpack-subresource-integrity) ajoute l'attribut `integrity` aux balises `<script>` et `<link>` émises.
* Vite : un plugin communautaire tel que [@small-tech/vite-plugin-sri](https://github.com/small-tech/vite-plugin-sri) calcule et injecte les hashes au moment du build.

Ils gardent le hash synchronisé avec le fichier, ce qui vous épargne la régénération à chaque changement sur vos propres assets bundlés.

## Ce n'est pas la même chose qu'un hash CSP [#ce-nest-pas-la-même-chose-quun-hash-csp]

Un hash SRI et un hash CSP se ressemblent, et on les confond facilement. Ils ne hashent pourtant pas la même chose.

* Le SRI hashe un **fichier externe** et va dans l'attribut `integrity` sur la balise.
* Une source CSP `'sha256-...'` hashe le **contenu d'un script inline** et va dans la directive `script-src` de votre politique de sécurité du contenu.

Si vous autorisez un bloc `<script>` inline, c'est le hash CSP qu'il vous faut, pas le SRI. [Comment générer un hash CSP (sha256)](/fr/blog/csp-hash-sha256) couvre ce cas.

## Où l'exiger [#où-lexiger]

L'attribut `integrity` s'ajoute balise par balise. Pour exiger le SRI sur tout un document d'un coup, il existe le header `Integrity-Policy`, qui demande au navigateur de refuser toute sous-ressource du périmètre chargée sans métadonnées d'intégrité.

```http
Integrity-Policy: blocked-destinations=(script)
```

Integrity-Policy est disponible depuis peu dans les versions actuelles de Chrome, Firefox et Safari. La référence [Integrity-Policy](/fr/docs/web-security/policies/integrity-policy) détaille les directives et le rapport qu'elle émet.

## Prochaines étapes [#prochaines-étapes]

Ajoutez `integrity` et `crossorigin` à vos scripts et feuilles de style cross-origin, épinglez leurs URL, et configurez votre bundler pour qu'il émette les hashes de vos propres assets. Si c'est un scanner qui vous amène ici, voyez [si un scanner a signalé votre SRI](/fr/blog/fix-sri-security-finding). Pour savoir quel code tiers vous chargez vraiment avant de commencer à le hasher, [commencez gratuitement](/register) et laissez CentralCSP inventorier vos scripts côté client.

## Sources [#sources]

* [MDN, Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity)
* [W3C Subresource Integrity specification](https://www.w3.org/TR/SRI/)
* [srihash.org, SRI hash generator](https://www.srihash.org/)

## Articles liés [#articles-liés]

* [Subresource Integrity (SRI) expliqué](/fr/blog/subresource-integrity-sri)
* [Comment générer un hash CSP (sha256)](/fr/blog/csp-hash-sha256)
* [Référence Subresource Integrity](/fr/docs/web-security/other/subresource-integrity)