Report-To vs Reporting-Endpoints

Il existe deux générations du header qui déclare les endpoints de reporting. Report-To est arrivé en premier (souvent appelé Reporting API v0) et Reporting-Endpoints l'a remplacé (v1). Pour presque tout, vous devriez utiliser Reporting-Endpoints. La seule exception est le Network Error Logging, qui exige toujours Report-To.

Les deux générations

Report-To (v0) déclare des groupes d'endpoints sous forme de JSON. Un groupe a un nom, un max_age qui met la configuration en cache, un tableau endpoints qui peut contenir plusieurs URL avec priorité et poids pour le failover, et un include_subdomains optionnel. Comme ce modèle reposait sur un cache valable pour toute l'origine, une configuration envoyée sur une seule réponse pouvait s'appliquer à d'autres pages de l'origine.

Report-To: { "group": "csp-endpoint", "max_age": 10886400,
             "endpoints": [ { "url": "https://<Endpoint-ID>.report.centralcsp.com" } ] }

Reporting-Endpoints (v1) abandonne tout cela au profit d'un dictionnaire de champs structurés de paires name="url" : une URL par nom, pas de groupes, pas de failover, pas de cache. Sa portée se limite à la réponse qui le transporte : il doit donc figurer sur chaque réponse susceptible de générer un report.

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

La spécification W3C Reporting ne définit que Reporting-Endpoints ; Report-To était un mécanisme de l'ère Chromium qui n'est jamais devenu un standard : il est marqué déprécié et non standard, et n'a jamais été implémenté ailleurs que dans Chromium.

Ce qui a changé et pourquoi

Le groupement et le cache qui faisaient la souplesse de la v0 sont précisément ce que les autres moteurs de navigateur n'étaient pas prêts à standardiser. La v1 troque cette souplesse contre un header minimal, valable pour une seule réponse, et c'est ce modèle-là qui est aujourd'hui largement pris en charge dans les navigateurs actuels.

La confusion à quatre voies autour de report-to

En pratique, la directive et le paramètre ne font que référencer un nom ; l'un des deux headers doit le déclarer :

• Reporting-Endpoints: csp-endpoint="https://..." déclare l'endpoint (v1).
• Report-To: { "group": "csp-endpoint", ... } le déclare à l'ancienne (v0).
• Content-Security-Policy: ...; report-to csp-endpoint le référence depuis CSP.
• Cross-Origin-Opener-Policy: same-origin; report-to="csp-endpoint" le référence depuis COOP.

Lequel utiliser

Par défaut, utilisez Reporting-Endpoints pour tout : CSP, COOP, COEP, Permissions-Policy, Document-Policy, Integrity-Policy, et les reports implicites de dépréciation, d'intervention et de crash. Ne gardez Report-To que sur les réponses qui envoient aussi le header NEL, car la v1 ne prend pas en charge le Network Error Logging. Pour CSP en particulier, la directive report-to a atteint le statut Baseline en 2026, vous n'avez donc besoin de conserver la directive dépréciée report-uri que comme repli pour les navigateurs très anciens, voir report-uri vs report-to.

FAQ

Report-To est-il déprécié ?

Oui. Report-To (Reporting API v0) était un mécanisme de l'ère Chromium qui n'est jamais devenu un standard, il est donc marqué déprécié et non standard. Reporting-Endpoints (v1) est le remplaçant moderne, défini par la spécification W3C Reporting et Baseline dans les navigateurs actuels. Report-To ne subsiste que pour le Network Error Logging, que la v1 ne prend pas en charge.

Faut-il à la fois Report-To et Reporting-Endpoints ?

Seulement si vous utilisez le Network Error Logging, qui exige encore le header hérité Report-To. Pour tout le reste, CSP, COOP, COEP, Permissions-Policy, Document-Policy, Integrity-Policy, et les reports implicites de dépréciation, d'intervention et de crash, Reporting-Endpoints seul suffit. Ne gardez Report-To que sur les réponses qui envoient aussi le header NEL.

report-to vs report-uri dans CSP ?

Ce sont des générations différentes de la directive de reporting de CSP. report-to nomme un endpoint déclaré par un header Reporting-Endpoints (ou Report-To) et achemine des reports structurés de la Reporting API. report-uri est la directive plus ancienne qui prend une URL directement. report-to a atteint le statut Baseline en 2026 ; ne gardez report-uri que comme repli pour les navigateurs très anciens.

Voir aussi

• Reporting-Endpoints header
• Report-To header
• Network Error Logging (NEL)
• Report-To vs Reporting-Endpoints, lequel utiliser

Sources

• Chrome, migrate to Reporting API v1
• MDN, Reporting-Endpoints header
• MDN, Report-To header