Violations CSP
Transformez les violations de Content Security Policy en une politique adaptée à votre site. Le sens des colonnes et les valeurs qui ne sont pas des origines.
Dernière mise à jour:
Toutes les ressources que votre CSP a bloquées, ou aurait bloquées sous un header Report-Only. C'est la page qui sert à construire une politique adaptée à votre site.
Colonnes
| Colonne | Signification |
|---|---|
| Directive | La directive CSP qui s'est déclenchée, par exemple script-src ou connect-src |
| Origine du document | L'origine de la page où cela s'est produit |
| Origine bloquée | L'origine de la ressource refusée |
| Navigateurs | Les navigateurs qui l'ont signalée |
| 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 |
Traiter un premier lot
- Filtrez sur une seule directive. Chaque directive est une décision distincte, et les mélanger fait paraître la liste plus longue qu'elle ne l'est.
- Pour chaque origine bloquée, décidez si elle a sa place sur votre site. Votre propre CDN a sa place. Un prestataire que vous reconnaissez aussi. Ce que vous ne savez pas expliquer, c'est le vrai constat.
- Ajoutez à la politique ce qui a sa place, retirez du site ce qui n'en a pas.
- Surveillez Dernière occurrence. Une entrée corrigée cesse d'apparaître. C'est votre confirmation, pas le nombre de reports, qui conserve tout son historique.
Avant de déployer une politique que vous venez de modifier, collez-la dans l'évaluateur CSP pour une relecture directive par directive, et utilisez le scanner CSP pour lire ce qu'une page en production envoie actuellement. Pour essayer un changement sans le livrer, l'extension Chrome applique une politique localement sur de vraies pages et montre ce qu'elle bloquerait.
Une origine bloquée n'est pas toujours une origine
Les valeurs ci-dessous indiquent que la violation portait sur un mode d'exécution plutôt que sur un hôte, et qu'ajouter quoi que ce soit à une allowlist ne les corrigera pas.
| Valeur | Ce qui s'est réellement passé |
|---|---|
inline | Un script ou un style inline s'est exécuté |
eval | Du code a appelé eval ou un équivalent |
wasm-eval | Du WebAssembly a été compilé depuis une chaîne |
data | Une URI data: a été chargée |
inline et eval demandent de modifier le code, ou d'ajouter un nonce ou un hash. Ce sont les violations à lire en premier, parce que ce sont celles qu'une vraie attaque produit.
Deux pièges
N'autorisez pas une origine juste pour faire taire un report. Ce report était la seule chose qui vous indiquait que cette ressource se charge.
N'ajoutez pas 'unsafe-inline' à script-src. Cela désactive l'essentiel de ce que la politique fait pour vous. Si des scripts inline sont inévitables, utilisez plutôt un nonce ou un hash.
Le bruit que vous ne pouvez pas corriger
Les extensions de navigateur injectent des scripts dans vos pages et votre politique les signale. Ce code n'est pas le vôtre et il n'y a rien à corriger. Écartez-les dès l'ingestion plutôt que d'y réfléchir à chaque fois, depuis Paramètres > Ingestion. Voir Filtres d'ingestion.