Comment déboguer les violations CSP dans Chrome 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, 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

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

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' » 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 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

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

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 (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.

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 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 note une politique et signale les sources faibles, et le guide CSP de MDN 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

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.

C'est ce que fait la suite CSP de CentralCSP : 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, pointer un header Report-Only vers la suite et voir les violations arriver depuis le trafic réel.

Les violations de tous les visiteurs, regroupées par directive et origine bloquée