# 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, car chacun nomme la directive déclenchée et la ressource bloquée. Le même événement existe sous deux formats de payload : 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). Le navigateur déduplique les reports : une ressource bloquée de nombreuses fois ne produit pas un report par tentative.
## Payload [#payload]
Le navigateur livre la même violation sous deux formes, selon la directive qui l'a acheminée. Basculez de l'une à l'autre 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 qu'un attaquant peut influencer, et n'affichez jamais l'un d'eux 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 couvrir le plus de navigateurs possible, envoyez à ses côtés la directive [`report-uri`](/fr/docs/web-security/policies/content-security-policy/directives/report-uri), pourtant dépréciée ; les navigateurs qui prennent en charge `report-to` ignorent `report-uri`, les deux ne produisent donc jamais de report en double.
```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, et c'est sur cette base que repose le [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 injection possible. Un pic soudain sur une directive est le signal qui doit vous alerter. L'[é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. Selon le WebIDL de la spec, `disposition` vaut `enforce` ou `report`, même si certains textes de MDN écrivent `reporting` : attendez-vous à `report`. Enfin, `blockedURL` est délibérément réduite au schéma, à l'hôte et au port pour les ressources cross-origin : vous voyez l'origine, pas 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` repose sur Chromium, d'où l'intérêt d'envoyer les deux : c'est aujourd'hui la configuration qui couvre le plus de navigateurs.
## 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)