report-uri vs report-to vs Reporting-Endpoints : quelle configuration de reporting CSP en 2026 ?

Le reporting de violations CSP souffre d’un désastre de nommage : une directive dépréciée (report-uri), une directive actuelle (report-to), un en-tête déprécié qui ressemble trait pour trait à la directive actuelle (Report-To) et l’en-tête qui l’a réellement remplacé (Reporting-Endpoints). Quatre noms, deux générations, un seul métier.

Voici la configuration à déployer en 2026, puis l’explication de chaque pièce :

Reporting-Endpoints: csp-endpoint="https://report.example.com/endpoint"
Content-Security-Policy: default-src 'self';
  report-uri https://report.example.com/endpoint;
  report-to csp-endpoint

Les deux directives de reporting, une déclaration d’endpoint. Les navigateurs qui comprennent report-to l’utilisent et ignorent report-uri. Tout ce qui est plus ancien retombe sur report-uri. Aucun navigateur ne rapporte deux fois. Cette combinaison ceinture-et-bretelles est ce que l’endpoint de CentralCSP accepte nativement, les trois mécanismes sur une même URL, précisément parce que la transition est loin d’être terminée.

(Autre question : si vous avez cherché « report uri » en pensant au service de reporting du même nom, il s’agit de Report URI, le produit de Scott Helme. Nous le comparons à CentralCSP dans un article dédié.)

Les quatre noms, démêlés

report-uri (directive, CSP Level 2). L’originale. Prend une URL directement, envoie un POST par violation, immédiatement. Dépréciée dans la spécification depuis des années, toujours honorée par tous les navigateurs en circulation. Son rapport est un objet JSON unique sous une clé csp-report, champs en kebab-case (blocked-uri, violated-directive), content type application/csp-report.

report-to (directive, CSP Level 3). La remplaçante. Prend un nom d’endpoint, pas une URL, et s’appuie sur un en-tête séparé pour résoudre ce nom. Les rapports transitent par la Reporting API : groupés, livrés de façon asynchrone (parfois plusieurs minutes plus tard), champs en camelCase (blockedURL, effectiveDirective) dans une enveloppe portant age, type, url et user_agent, content type application/reports+json.

Report-To (en-tête, Reporting API v0). Déprécié. Déclarait les endpoints dans un blob JSON. Son quasi-jumeau en minuscules étant une directive actuelle, il a semé la confusion chez une génération d’ingénieurs et dans la documentation d’au moins un éditeur de sécurité. Si votre configuration le définit, migrez.

Reporting-Endpoints (en-tête, Reporting API v1). Actuel. Une ligne, des correspondances nom-vers-URL, uniquement des URL HTTPS entre guillemets :

Reporting-Endpoints: csp-endpoint="https://report.example.com/endpoint", default="https://report.example.com/other"

Il transporte aussi tous les autres types de rapports de la Reporting API (dépréciation, crash, violations COOP), d’où l’importance des noms : un seul en-tête peut alimenter plusieurs flux vers plusieurs endpoints.

Ce qui a changé en 2026

Le support, enfin. Reporting-Endpoints a atteint le statut baseline multi-navigateurs en septembre 2024. La directive report-to a suivi et, d’après les données de compatibilité de MDN, est baseline sur les dernières versions des navigateurs depuis mars 2026.

Lisez bien : « les dernières versions ». Les parcs d’entreprise figés sur des navigateurs anciens, les WebViews embarquées et la longue traîne d’appareils jamais mis à jour ne parlent toujours que report-uri. Abandonner la directive héritée aujourd’hui, c’est devenir aveugle exactement sur les clients les plus susceptibles de faire tourner des logiciels obsolètes et vulnérables. Notre recommandation tient tant que vos propres statistiques de user-agents ne disent pas le contraire : livrez les deux directives, laissez chaque navigateur choisir.

Les différences qui mordent vraiment

Deux de ces lignes causent l’essentiel de la confusion sur le terrain. Le groupage fait que « j’ai déployé report-to et rien n’arrive » relève souvent de la simple impatience, et il rend la Reporting API peu adaptée, seule, à la détection d’incidents en temps réel. Quant à la règle HTTPS-uniquement, elle échoue en silence : un endpoint http:// dans Reporting-Endpoints ne produit ni erreur, ni avertissement, ni rapport, jamais.

La divergence de formats signifie aussi qu’un collecteur maison a besoin de deux parseurs et d’un aiguillage sur le content type. Les endpoints managés absorbent tout cela : CentralCSP normalise les deux formats en un seul flux indexé, si bien qu’une violation a la même tête dans votre dashboard qu’elle vienne d’un navigateur de 2019 ou du Chrome d’hier. Le même endpoint accepte aussi les autres types de rapports de la Reporting API (NEL, crash, dépréciation, COOP, COEP : douze au total) si vous choisissez de les y envoyer. La documentation de configuration du reporting donne les lignes d’en-tête exactes.

Checklist de migration

1. Ajoutez Reporting-Endpoints avec un endpoint HTTPS nommé.
2. Ajoutez report-to <nom> à votre CSP, en conservant la ligne report-uri existante.
3. Supprimez tout en-tête Report-To (T majuscule) hérité de la Reporting API v0.
4. Confirmez que votre collecteur gère application/reports+json et ses tableaux groupés.
5. Réexaminez l’abandon de report-uri quand vos statistiques de trafic diront que les clients anciens ont disparu. Pour la plupart des sites, ce jour est encore loin.

Le désordre des noms est permanent. La configuration, elle, n’a aucune raison d’être compliquée.