La directive report-uri, le canal de rapport CSP déprécié

La directive CSP obsolète report-uri envoie les rapports de violation à une URL que vous définissez. Passez à report-to avec Reporting-Endpoints.

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é.

Obsolète

report-uri est obsolète au profit de la directive report-to associée au header 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 très anciens. Voir Prise en charge par les navigateurs.

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 l'aurait bloqué, le navigateur construit un rapport et l'envoie en POST à chaque URL de cette directive.

Utilisez plutôt le remplacement :

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

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

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

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

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 :

{
  "csp-report": {
    "document-uri": "https://api-next.centralcsp.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 pour la référence des champs.

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 réceptacle 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.

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 abandonne silencieusement les rapports, vous laissant aveugle à 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

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

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

report-uri est elle-même le mécanisme de reporting historique : elle délivre le payload csp-report encapsulé montré ci-dessus. Le pipeline moderne délivre les mêmes violations sous forme de rapports csp-violation via la Reporting API.

Prise en charge par les navigateurs

Largement prise en charge sur Chromium, Firefox et Safari. La directive moderne 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.

report-uri