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. Le modèle en cache et ambiant signifiait qu'une configuration envoyée sur une 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. Il est porté par la réponse sur laquelle il est servi, il doit donc être présent sur chaque réponse pouvant 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, ce qui explique qu'il soit marqué déprécié et non standard et n'ait jamais été diffusé 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 échange cette souplesse contre un header simple, par réponse, et ce modèle plus simple est désormais 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 le Network Error Logging n'est pas pris en charge par la v1. 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 délivre 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