# Violations CSP (/fr/docs/platform/monitoring/csp) 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. La page Violations CSP, avec ses compteurs, son graphique de tendance et le tableau des violations agrégées ## Colonnes [#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 [#traiter-un-premier-lot] 1. **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. 2. **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. 3. **Ajoutez à la politique ce qui a sa place, retirez du site ce qui n'en a pas.** 4. **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](/tools/csp-evaluator) pour une relecture directive par directive, et utilisez le [scanner CSP](/tools/csp-scanner) pour lire ce qu'une page en production envoie actuellement. Pour essayer un changement sans le livrer, l'[extension Chrome](/tools/extension) applique une politique localement sur de vraies pages et montre ce qu'elle bloquerait. ## Une origine bloquée n'est pas toujours une origine [#une-origine-bloquée-nest-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 [#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 [#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](/fr/docs/platform/websites/reporting-settings). ## Étapes suivantes [#étapes-suivantes] * [Hashes CSP](/fr/docs/platform/monitoring/script-hash) * [Référence Content Security Policy](/fr/docs/web-security/policies/content-security-policy)