# Violation CSP (/fr/docs/web-security/reporting-api/reports/csp-violation)
Un report `csp-violation` vous indique que quelque chose sur la page a enfreint une règle de [Content Security Policy (CSP)](/fr/docs/web-security/policies/content-security-policy) : un script, un style, une image, une frame ou une connexion bloqués. C'est le type de report le plus utile pour resserrer une politique, parce que chacun nomme la directive qui s'est déclenchée et la ressource qui a été bloquée. Il existe deux formats de payload pour le même événement, la forme moderne de la Reporting API et la forme legacy `report-uri`.
## Quand le navigateur l'envoie [#quand-le-navigateur-lenvoie]
Le navigateur envoie un report chaque fois que la politique bloque (ou, en mode Report-Only, bloquerait) une ressource ou une violation inline. Il se déclenche dans les deux modes ; le champ `disposition` les distingue (`enforce` pour une politique bloquante, `report` pour Report-Only). Les reports sont dédupliqués, donc une ressource bloquée de nombreuses fois ne produit pas un report par tentative.
## Payload [#payload]
La même violation est livrée sous deux formes selon la directive qui l'a routée. Basculez entre elles ici :
La directive `report-uri` poste un objet unique enveloppé dans `csp-report` avec des champs en kebab-case et `Content-Type: application/csp-report`, et non le tableau `application/reports+json`. Les deux ne sont pas interchangeables ; un endpoint qui accepte les deux doit aiguiller selon le `Content-Type`.
application/reports+json (modern)
application/csp-report (legacy)
```json
{
"type": "csp-violation",
"age": 53,
"url": "https://example.com/",
"user_agent": "Mozilla/5.0 ...",
"body": {
"documentURL": "https://example.com/",
"referrer": "https://www.google.com/",
"blockedURL": "https://apis.google.com/js/platform.js",
"effectiveDirective": "script-src-elem",
"originalPolicy": "default-src 'self'; report-to csp-endpoint",
"sourceFile": "https://example.com/",
"sample": "",
"disposition": "enforce",
"statusCode": 200,
"lineNumber": 1441,
"columnNumber": 59
}
}
```
```json
{
"csp-report": {
"document-uri": "https://example.com/",
"violated-directive": "script-src-elem",
"effective-directive": "script-src-elem",
"original-policy": "default-src 'self'; report-uri /csp-reports",
"blocked-uri": "https://apis.google.com/js/platform.js",
"disposition": "enforce",
"status-code": 200,
"script-sample": ""
}
}
```
## Référence des champs [#référence-des-champs]
Le body moderne utilise le camelCase ; la forme legacy utilise le nom en kebab-case entre parenthèses.
| Champ (nom legacy) | Signification |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `documentURL` (`document-uri`) | La page où la violation s'est produite. |
| `referrer` | Le referrer du document, le cas échéant. |
| `blockedURL` (`blocked-uri`) | La ressource qui a été bloquée. Tronquée au schéma, à l'hôte et au port quand elle est cross-origin. |
| `effectiveDirective` (`effective-directive`) | La directive qui s'est réellement déclenchée (par exemple `script-src-elem`). |
| `originalPolicy` (`original-policy`) | Le texte complet de la politique appliquée par le navigateur. |
| `sourceFile` | L'origine de la violation, pour les cas inline. |
| `sample` (`script-sample`) | Les \~40 premiers caractères du contenu inline incriminé, uniquement quand la directive porte `'report-sample'`. |
| `disposition` | `enforce` ou `report`. |
| `statusCode` (`status-code`) | Le statut HTTP de la réponse du document. |
| `lineNumber` / `columnNumber` | L'emplacement pour les violations inline. |
Le `violated-directive` legacy est un alias historique de `effective-directive`. Traitez chaque champ comme une entrée influençable par un attaquant, et n'en affichez jamais un dans une page sans l'échapper.
## Comment le recevoir [#comment-le-recevoir]
Déclarez un endpoint et pointez la politique vers lui avec la directive [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to). Pour la couverture navigateur la plus large, envoyez la directive [`report-uri`](/fr/docs/web-security/policies/content-security-policy/directives/report-uri) dépréciée à ses côtés ; les navigateurs qui prennent en charge `report-to` ignorent `report-uri`, donc les deux ne créent jamais de double report.
```http
Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com"
```
```http
Content-Security-Policy:
default-src 'self';
report-uri https://.report.centralcsp.com;
report-to csp-endpoint
```
CentralCSP ingère les deux formats et les normalise, ce qui est la base du [tableau de bord des violations CSP](/fr/docs/platform/monitoring/csp).
## Ce qu'il vous apprend sur la sécurité [#ce-quil-vous-apprend-sur-la-sécurité]
Lisez `effectiveDirective` et `blockedURL` ensemble. Une violation `script-src` pointant vers un hôte que vous reconnaissez signifie généralement que la politique est trop stricte. Une violation pointant vers un hôte que vous ne reconnaissez pas, ou un `sample` inline que vous n'avez pas écrit, mérite d'être examinée comme une possible injection. Un pic soudain sur une directive est le signal qui invite à regarder. Le [évaluateur CSP](/tools/csp-evaluator) aide à resserrer la politique qui a produit les reports.
## Pièges [#pièges]
Les noms des champs du body sont en camelCase dans la forme moderne et en kebab-case dans la forme legacy. La valeur `disposition` selon le WebIDL de la spec est `enforce` ou `report`, même si certaines proses MDN écrivent `reporting` ; attendez-vous à `report`. Et `blockedURL` est délibérément réduite au schéma, à l'hôte et au port pour les ressources cross-origin, donc vous voyez l'origine plutôt que le chemin exact.
## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs]
La livraison legacy `report-uri` a la prise en charge la plus large, y compris Firefox et Safari. La livraison moderne `report-to` est portée par Chromium, c'est pourquoi envoyer les deux est la configuration la plus couvrante aujourd'hui.
## Voir aussi [#voir-aussi]
* [Content Security Policy](/fr/docs/web-security/policies/content-security-policy)
* [directive report-uri](/fr/docs/web-security/policies/content-security-policy/directives/report-uri)
* [Les champs du report de violation CSP expliqués](/fr/blog/csp-violation-report-fields)
* [Le format de livraison des reports](/fr/docs/web-security/reporting-api/concepts/report-delivery-format)
* [Header Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Monitoring CSP dans CentralCSP](/fr/docs/platform/monitoring/csp)
## Sources [#sources]
* [MDN, CSPViolationReportBody](https://developer.mozilla.org/en-US/docs/Web/API/CSPViolationReportBody)
* [W3C, Content Security Policy Level 3 reporting](https://www.w3.org/TR/CSP3/#reporting)
* [MDN, CSP report-uri](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/report-uri)