# report-uri (/fr/docs/web-security/policies/content-security-policy/directives/report-uri)



La directive `report-uri` indique au navigateur où envoyer en POST un rapport de violation Content Security Policy (CSP) lorsqu'une page enfreint la politique. Le navigateur envoie un document JSON à l'URL que vous nommez, pour que vous puissiez voir ce que la politique a bloqué.

<Callout type="error" title="Obsolète">
  `report-uri` est obsolète au profit de la directive [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) associée au header [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints), qui achemine les violations CSP via la Reporting API, le même pipeline de livraison que le navigateur utilise pour tous les autres types de rapports, au lieu d'un POST propre à CSP. Les navigateurs qui prennent en charge `report-to` ignorent `report-uri`. Comme `report-to` a atteint le statut Baseline en 2026 et fonctionne désormais dans les navigateurs actuels, ne conservez `report-uri` que comme repli pour les navigateurs très anciens. Voir [Prise en charge par les navigateurs](#prise-en-charge-par-les-navigateurs).
</Callout>

La directive contrôle une seule chose : la destination des rapports de violation CSP. Elle ne bloque, n'autorise ni ne restreint aucune ressource. Lorsqu'une politique appliquée bloque quelque chose, ou qu'une politique [Content-Security-Policy-Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only) l'aurait bloqué, le navigateur construit un rapport et l'envoie en POST à chaque URL de cette directive.

Utilisez plutôt son remplaçant :

```http
Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
```

```http
Content-Security-Policy:
    default-src 'self';
    report-to csp-endpoint
```

## Chaîne de repli [#chaîne-de-repli]

`report-uri` n'a pas de repli. `default-src` ne la couvre pas. Si vous l'omettez (ainsi que `report-to`), la politique s'applique toujours, mais vous ne recevez aucun rapport et n'avez aucune trace de ce qu'elle a bloqué.

## Valeurs [#valeurs]

Une ou plusieurs URL, séparées par des espaces. Chacune doit être une URL absolue ou relative vers laquelle le navigateur peut envoyer un POST. Utilisez des endpoints HTTPS.

| Valeur                          | Statut      | Description                                                                                                                                  |
| ------------------------------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Une ou plusieurs URL de rapport | ⚠️ Déprécié | Destinations vers lesquelles le navigateur envoie les rapports de violation en POST. Toute la directive est obsolète ; utilisez `report-to`. |

## Exemples [#exemples]

```http
Content-Security-Policy:
    default-src 'self';
    report-uri https://<Endpoint-ID>.report.centralcsp.com
```

Le navigateur envoie un POST avec `Content-Type: application/csp-report`. Le corps est un objet JSON avec une seule clé de premier niveau `csp-report` :

```json
{
  "csp-report": {
    "document-uri": "https://example.com/page",
    "referrer": "",
    "violated-directive": "script-src",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; report-uri https://<Endpoint-ID>.report.centralcsp.com",
    "blocked-uri": "https://evil.example/x.js",
    "status-code": 200
  }
}
```

Cette forme diffère du payload de `report-to`, qui est un tableau d'objets en camelCase. Voir la page [Rapport de violation CSP](/fr/docs/web-security/reporting-api/reports/csp-violation) pour la référence des champs.

## Notes de sécurité [#notes-de-sécurité]

`report-uri` ne peut pas être définie via un élément `<meta http-equiv>` ; elle ne fonctionne que comme header de réponse HTTP. Les rapports peuvent contenir l'URL bloquée, l'URL du document et (avec `'report-sample'`) un extrait du contenu bloqué, alors traitez l'endpoint comme un point de collecte de données potentiellement sensibles et servez-le en HTTPS.

Vous pouvez collecter et agréger ces rapports avec CentralCSP, et confirmer le câblage avec le [vérificateur de configuration de la Reporting API](/tools/reporting-api).

## Contournements et risques connus [#contournements-et-risques-connus]

La directive ne fait que rapporter ; elle n'empêche jamais une attaque à elle seule. Un endpoint mal configuré ou injoignable perd les rapports en silence et vous laisse sans visibilité sur ce que la politique bloque. Comme le payload inclut des URL et des échantillons optionnels, une politique `'report-sample'` trop large peut divulguer des fragments du contenu de la page à l'endpoint.

## Recommandation [#recommandation]

```http
Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
```

```http
Content-Security-Policy:
    default-src 'self';
    report-to csp-endpoint;
    report-uri https://<Endpoint-ID>.report.centralcsp.com
```

Migrez vers `report-to` avec `Reporting-Endpoints` comme voie de reporting principale ; les trois moteurs le prennent désormais en charge (MDN ; notes de version de Firefox). Ne gardez `report-uri` dans la politique que pour couvrir les anciennes versions de navigateurs non mises à jour ; tout navigateur qui comprend `report-to` l'ignore.

## Reporting [#reporting]

`report-uri` est elle-même le mécanisme de reporting historique : elle envoie le payload `csp-report` encapsulé montré ci-dessus. Le pipeline moderne transmet les mêmes violations sous forme de [rapports `csp-violation`](/fr/docs/web-security/reporting-api/reports/csp-violation) via la Reporting API.

## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs]

Largement prise en charge sur Chromium, Firefox et Safari. La directive moderne [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) a atteint le statut Baseline en 2026 et fonctionne désormais dans ces mêmes navigateurs, vous n'avez donc plus besoin de `report-uri` pour couvrir Firefox ou Safari. Ne conservez `report-uri` que comme repli pour les navigateurs très anciens et non mis à jour, antérieurs à `report-to`.

## Voir aussi [#voir-aussi]

* [Directive report-to](/fr/docs/web-security/policies/content-security-policy/directives/report-to)
* [Header Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Header Content-Security-Policy-Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only)
* [report-uri vs report-to](/fr/blog/report-uri-vs-report-to)

## Sources [#sources]

* [MDN, CSP report-uri](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/report-uri)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [MDN, notes de version de Firefox](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/149)