# Comment déboguer les violations CSP dans Chrome DevTools (/fr/blog/debug-csp-violations-devtools)





Quand une politique de sécurité du contenu (CSP) bloque quelque chose, le navigateur vous
le signale dans la console, et le message nomme à la fois la ressource refusée et la
directive à l'origine du refus. La façon la plus rapide de déboguer une violation est de
lire ce message, puis d'ouvrir le panneau Issues de DevTools, qui décompose la même
violation en ressource bloquée, directive violée, emplacement source et lien vers
l'élément qui l'a déclenchée. À partir de là, vous reliez la directive au correctif.

Cet article passe en revue la lecture du message console « Refused to... », l'ouverture et
l'utilisation du panneau Issues de [Chrome DevTools](https://developer.chrome.com/docs/devtools), les messages courants que vous verrez et ce que chacun signifie, ainsi que la façon de transformer un message en la modification de directive qui le corrige. Il se termine par la seule chose que DevTools ne peut pas vous dire.

## Lisez d'abord le message console [#lisez-dabord-le-message-console]

La ligne de console est le signal le plus rapide. Un script bloqué produit quelque chose
comme ceci :

```text
Refused to load the script 'https://cdn.example/widget.js' because it
violates the following Content Security Policy directive: "script-src 'self'".
```

Lisez-le en trois parties :

* **Le verbe et la ressource.** « Refused to load the script
  '[https://cdn.example/widget.js](https://cdn.example/widget.js)' » vous indique ce que le navigateur a bloqué et son URL.
  Le verbe change selon le type : « Refused to load », « Refused to execute inline
  script », « Refused to apply inline style », « Refused to connect to », « Refused to
  frame ».
* **La directive qui l'a bloqué.** « violates the following Content Security Policy
  directive: script-src 'self' » est la règle qui n'a pas matché. C'est la directive que
  vous allez changer, ou celle dont la source list ne contient pas l'origine dont vous
  avez besoin.
* **Le mode.** Si le message dit que la ressource « would be blocked » ou mentionne
  report-only, la politique est sur [`Content-Security-Policy-Report-Only`](/fr/blog/csp-enforce-vs-report-only) et rien n'a encore été réellement bloqué. Une politique appliquée dit « Refused to » sans détour.

La console suffit pour une lecture rapide, mais elle ne vous renvoie pas toujours vers
l'élément ni n'affiche proprement la source. Pour cela, utilisez le panneau Issues.

## Utilisez le panneau Issues [#utilisez-le-panneau-issues]

Le panneau Issues transforme chaque violation en une fiche structurée au lieu d'une chaîne
sur une seule ligne. Pour une violation, il affiche :

* la **directive violée** (par exemple `script-src`),
* la **ressource bloquée** (l'URL, ou « inline » pour du code inline),
* l'**emplacement source** (le fichier et la ligne qui ont chargé la ressource),
* un **lien vers l'élément** dans le panneau Elements qui l'a causée.

Pour l'ouvrir : cliquez sur le compteur **Issues** dans la barre d'action en haut de
DevTools, ou utilisez **More tools** puis **Issues** depuis le menu de DevTools (les trois
points). Rechargez la page avec DevTools ouvert pour capturer les violations. Le panneau
Issues regroupe les violations identiques, donc un script bloqué à chaque navigation
apparaît une seule fois avec un compteur, ce qui est plus facile à parcourir que les
lignes de console répétées.

Le lien vers l'élément est ce qui fait gagner du temps. Cliquez dessus et DevTools saute
exactement au `<script>`, `<link>`, `<img>` ou `<iframe>` qui a déclenché le blocage, pour
que vous voyiez si c'est votre code ou un tiers injecté.

## Messages courants et leur signification [#messages-courants-et-leur-signification]

Le verbe du message indique le type de ressource, et le type de ressource indique la
directive. Les plus fréquents :

* **« Refused to load the script ... »** Un script depuis une URL a été bloqué par
  [`script-src`](/fr/docs/web-security/policies/content-security-policy/directives/script-src) (ou `default-src` en repli). L'origine n'est pas sur la source list.
* **« Refused to execute inline script ... »** Un `<script>` inline ou un event handler
  inline (`onclick=...`) a été bloqué parce que `script-src` n'a ni `'unsafe-inline'`, ni
  nonce, ni hash correspondant. C'est le comportement attendu d'une politique stricte.
* **« Refused to apply inline style ... »** Un attribut `style=` inline ou un bloc
  `<style>` a été bloqué par `style-src` pour la même raison.
* **« Refused to connect to ... »** Une requête `fetch`, `XMLHttpRequest`, WebSocket ou
  `EventSource` a été bloquée par `connect-src`.
* **« Refused to load the image ... »** Une URL d'image a été bloquée par `img-src`.
* **« Refused to frame ... »** Une source d'`<iframe>` a été bloquée par `frame-src`.
* **« Refused to evaluate a string as JavaScript ... »** Un appel à `eval`,
  `new Function` ou similaire a été bloqué parce que `script-src` n'inclut pas
  `'unsafe-eval'`. Le correctif consiste généralement à retirer l'`eval`, pas à ajouter le
  mot-clé.

Les violations de script inline et d'`eval` sont les deux qui prennent les gens au
dépourvu, car elles ne concernent pas une origine oubliée. Elles signifient que la
politique fait son travail et que la page repose sur de l'exécution inline. La bonne
réponse est un nonce ou un hash pour le bloc inline que vous contrôlez, pas
`'unsafe-inline'`, qui désactive la protection pour tout. Le raisonnement est dans
[pourquoi vous ne devriez jamais utiliser unsafe-inline en CSP](/fr/blog/unsafe-inline-csp).

## Reliez le message au correctif [#reliez-le-message-au-correctif]

Une fois que vous connaissez la directive et la ressource, la modification est mécanique :

* **Une ressource cross-origin légitime a été bloquée.** Ajoutez son origine exacte à la
  directive nommée dans le message. Si `connect-src` a bloqué `https://api.example`,
  ajoutez cette origine à `connect-src`. Ajoutez l'origine précise, pas un wildcard.
* **Votre propre script ou style inline a été bloqué.** Donnez-lui un nonce (une nouvelle
  valeur aléatoire par réponse, dans la directive et sur l'élément) ou un hash. Voir
  [débuter avec la politique de sécurité du contenu](/fr/blog/get-started-with-csp) pour
  la configuration du nonce.
* **Un `eval` a été bloqué.** Trouvez le code qui appelle `eval` ou `new Function` et
  remplacez-le. Une dépendance qui a besoin d'`eval` mérite d'être signalée ; ajouter
  `'unsafe-eval'` affaiblit toute la politique.
* **Vous ne reconnaissez pas du tout la ressource.** C'est le cas intéressant. Une origine
  que vous n'avez pas ajoutée, sur une page que vous n'avez pas modifiée, peut être une
  extension, ou un script injecté. Ne l'autorisez pas par réflexe. Vérifiez le lien vers
  l'élément dans le panneau Issues pour voir d'où elle vient.

Si vous voulez confirmer que la modification est saine avant de la déployer, le
[évaluateur CSP](/tools/csp-evaluator) note une politique et signale les sources faibles,
et le [guide CSP de MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)
contient la référence par directive. Après modification, rechargez avec le panneau Issues
ouvert et confirmez que la violation a disparu.

## DevTools ne voit que votre machine [#devtools-ne-voit-que-votre-machine]

Le panneau Issues affiche les violations sur **votre** navigateur, sur **cette** page,
dans **cette** session, avec **vos** extensions. C'est exactement ce que vous voulez
pendant que vous corrigez une page. Ce n'est pas ce qui vous dit que la politique est sûre
à appliquer pour tout le monde.

Les vrais utilisateurs rencontrent des violations que vous ne verrez jamais en local : des
scripts tiers qui ne se chargent que dans certaines régions, une extension que vous n'avez
pas, une page que vous n'avez pas testée, un tag fournisseur modifié du jour au lendemain.
Aucun de ces cas n'apparaît dans votre DevTools. Pour appliquer une politique sans casser
la longue traîne, vous collectez les reports de violation du trafic réel au lieu de vous
fier à une seule machine. Pour le contenu de ces reports et la correspondance entre les
champs et ce que vous voyez dans DevTools, voir
[les champs d'un report de violation CSP](/fr/blog/csp-violation-report-fields).

C'est ce que fait la [suite CSP de CentralCSP](/platform/csp-builder) : elle ingère les reports
que vos vrais utilisateurs génèrent, les regroupe par directive et par origine, sépare le
bruit des extensions des vrais problèmes, et montre les scripts qui tournent sur chaque
page, pour que vous débogiez à partir de preuves de production plutôt que d'un seul onglet
de navigateur. Vous pouvez [démarrer un essai gratuit](/register), pointer un header
Report-Only vers la suite et voir les violations arriver depuis le trafic réel.

<img alt="Les violations de tous les visiteurs, regroupées par directive et origine bloquée" src="__img0" width="1365" height="691" />

## Sources [#sources]

* [Chrome DevTools documentation](https://developer.chrome.com/docs/devtools)
* [Chrome DevTools, the Issues panel](https://developer.chrome.com/docs/devtools/issues)
* [MDN, Content Security Policy guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)

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

* [Débuter avec la politique de sécurité du contenu](/fr/blog/get-started-with-csp)
* [Pourquoi vous ne devriez jamais utiliser unsafe-inline en CSP](/fr/blog/unsafe-inline-csp)
* [Mode enforce comparé à report-only en CSP](/fr/blog/csp-enforce-vs-report-only)