# Violations d'intégrité (/fr/docs/platform/monitoring/integrity-policy)





Les scripts qui se sont chargés sans métadonnées Subresource Integrity valides, ou avec des métadonnées qui ne correspondaient pas. Chaque ligne est un script dont personne n'a vérifié le contenu.

<img alt="Les scripts sans intégrité, chaque URL de CDN listée avec l'origine du document qui l'a chargée, les navigateurs qui l'ont signalée et sa disposition" src="__img0" width="1359" height="388" />

## Colonnes [#colonnes]

| Colonne             | Signification                                                        |
| ------------------- | -------------------------------------------------------------------- |
| Script              | Le script qui a échoué à la vérification                             |
| Origine du document | La page qui l'a chargé                                               |
| Navigateurs         | Les navigateurs qui l'ont signalé                                    |
| Disposition         | Appliqué signifie bloqué, Report-only signifie que cela l'aurait été |
| Reports             | Les reports regroupés dans cette ligne                               |
| Dernière occurrence | L'occurrence la plus récente                                         |

Le détail ajoute **Destination**, qui indique en tant que quoi le navigateur récupérait la ressource.

## La correction [#la-correction]

Ajoutez un attribut `integrity` avec le bon hash, plus `crossorigin` pour que le navigateur puisse le vérifier :

```html
<script
  src="https://cdn.example.com/lib.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>
```

Générez les hash au moment du build. Un attribut `integrity` maintenu à la main se périme à la prochaine mise à jour du prestataire et se transforme en panne, ce qui est la raison habituelle pour laquelle les équipes abandonnent SRI après l'avoir essayé.

Pour une valeur ponctuelle, le [générateur SRI](/tools/sri-hash) calcule le hash depuis l'URL d'un script ou d'une feuille de style et vérifie les headers CORS dont la vérification a besoin, l'autre moitié des raisons pour lesquelles SRI échoue en silence.

## Deux cas que la correction ne couvre pas [#deux-cas-que-la-correction-ne-couvre-pas]

**Une URL dont le contenu change à chaque requête** ne peut pas porter de hash statique. Figez-la d'abord sur une URL versionnée, puis ajoutez `integrity`.

**Un prestataire qui refuse de publier des assets versionnés stables** relève d'une décision sur la chaîne d'approvisionnement, pas d'un problème de balisage. Vos options sont d'en héberger une copie vous-même, d'abandonner la dépendance, ou d'accepter du contenu non vérifié et de le surveiller via les [hashes CSP](/fr/docs/platform/monitoring/script-hash).

## Recoupement avec les hashes CSP [#recoupement-avec-les-hashes-csp]

Un script présent sur les deux pages est un script dont vous savez qu'il change et que vous n'avez pas figé. Les hashes CSP enregistrent la valeur de hash de tout ce qui s'exécute, cette page enregistre les endroits où une vérification était attendue et n'a pas eu lieu.

## Étapes suivantes [#étapes-suivantes]

* [Hashes CSP](/fr/docs/platform/monitoring/script-hash)
* [Référence Integrity-Policy](/fr/docs/web-security/policies/integrity-policy)