Reporting-Endpoints header, syntaxe et exemples

Le header moderne qui déclare des endpoints de reporting nommés pour CSP, COOP, COEP et les autres politiques du navigateur.

Reporting-Endpoints est le header de réponse qui nomme les URL où le navigateur doit envoyer les reports. Vous donnez un nom à chaque endpoint, puis des politiques comme la Content Security Policy (CSP), COOP et COEP reprennent ce nom pour y acheminer leurs reports. C'est le remplaçant moderne du header historique Report-To.

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

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

Qu'est-ce que le header Reporting-Endpoints

C'est un dictionnaire de champs structurés : une liste de paires name="url" séparées par des virgules. Le nom est un libellé arbitraire que vous choisissez ; la valeur est l'URL de l'endpoint entre guillemets. Déclarer un endpoint ne fait rien à lui seul. Les reports ne circulent qu'une fois qu'une politique nomme l'un de ces endpoints : le header et la politique vont toujours par paire.

Valeurs et rôle de chacune

Valeur	Statut	Description
`name="https://url/"`	✅ Bon	Une association entre un nom et un endpoint. Une politique le référence par `name`.
Une URL d'endpoint HTTPS	✅ Bon	L'adresse où les reports sont envoyés en POST. Doit être en HTTPS (potentiellement digne de confiance).
Un endpoint `http://`	❌ Risqué	URL non sécurisée. Le navigateur l'ignore, les reports disparaissent donc. Utilisez HTTPS.
`a="url1", b="url2"`	✅ Bon	Plusieurs endpoints séparés par des virgules ; acheminez chaque politique vers une URL différente.
`default="https://url/"`	✅ Bon	L'endpoint de repli pour les types de report sans cible explicite (deprecation, intervention, crash).

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

Si vos reports de dépréciation ou de crash n'arrivent jamais, la cause habituelle est un endpoint default manquant : ces types n'utilisent aucun endpoint nommé. Voir l'endpoint default pour comprendre comment le repli est résolu.

Valeurs non sûres à éviter

L'URL de l'endpoint doit être en HTTPS (potentiellement digne de confiance). Le navigateur ignore silencieusement un endpoint HTTP non sécurisé et une URL invalide : une valeur mal configurée fait donc disparaître les reports sans erreur.

Aucun paramètre n'est défini pour un endpoint, et tout paramètre supplémentaire est ignoré silencieusement. Ne pointez les endpoints que vers des hôtes que vous contrôlez ou en qui vous avez confiance : les corps de report peuvent inclure des URL de pages et de courts échantillons de contenu inline, un endpoint non fiable est donc une voie de fuite de données.

Pourquoi ce header existe

Il remplace Report-To par un modèle plus simple. Report-To portait des groupes d'endpoints, du cache et du failover qui n'ont jamais été standardisés et n'ont jamais été diffusés que dans Chromium. Reporting-Endpoints se réduit à une table name="url" valable pour une réponse, ce qui colle à la façon dont les politiques sont livrées (par réponse) et que les autres moteurs de navigateur pouvaient reprendre. Voir Report-To vs Reporting-Endpoints.

Ce contre quoi il protège

Rien directement : le header n'applique aucune politique. Ce qu'il apporte, c'est la visibilité. C'est le câblage qui transforme une violation de politique, une dépréciation ou un crash autrement silencieux en un signal que vous pouvez collecter, surveiller et transformer en alerte. La protection vient de la politique ; c'est par ce header que vous apprenez qu'elle s'est déclenchée.

Contournements connus et limites

Le header n'affecte que le document sur lequel il est servi, il doit donc être présent sur chaque réponse pouvant générer un report ; le servir uniquement sur la page d'accueil laisse le reste du site silencieux. Il n'y a pas de cache max_age, pas de groupes d'endpoints, et pas de failover (une URL par nom). Et il ne livre pas les reports de Network Error Logging, qui exigent toujours Report-To.

Risques d'une mauvaise configuration

Le mode d'échec est silencieux. Une faute de frappe dans le nom de l'endpoint signifie que le report-to d'une politique ne pointe vers rien et qu'aucun report n'est envoyé, sans erreur nulle part. Un header absent de certaines réponses vous donne une couverture partielle qui ressemble à un faible trafic plutôt qu'à une lacune.

Recommandation

Déclarez un seul endpoint HTTPS clairement nommé et référencez-le depuis chaque politique. Un unique csp-endpoint couvre le cas courant ; n'ajoutez un default que lorsque vous collectez aussi les reports émis par le navigateur (deprecation, intervention, crash).

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

L'URL de l'endpoint doit être en HTTPS. La Reporting API n'accepte qu'un endpoint potentiellement digne de confiance, et le navigateur abandonne une URL http:// sans erreur. Servez le même header sur chaque réponse pouvant générer un report pour que la couverture soit complète.

Comment le configurer

Ajoutez le header sur chaque réponse censée produire des reports, nommez un ou plusieurs endpoints, et référencez-les depuis chaque politique. Pour vérifier qu'un site en production est correctement câblé sans écrire de récepteur, passez par le vérificateur de configuration Reporting API ; pour collecter et agréger les reports sans monter de backend, pointez l'endpoint vers le reporting CentralCSP.

Prise en charge par les navigateurs

Baseline 2026 : Reporting-Endpoints et la directive CSP report-to sont largement pris en charge dans les navigateurs actuels, dont Chrome, Edge, Firefox et Safari (et leurs équivalents mobiles), la livraison des reports via la Reporting API n'est donc plus réservée à Chromium. Le Network Error Logging fait exception : il exige toujours l'ancien header Report-To et reste réservé à Chromium.

Reporting-Endpoints header