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 référencent ce nom pour router 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 une politique fonctionnent donc toujours en paire.

Valeurs et rôle de chacune

Valeur	Statut	Description
`name="https://url/"`	✅ Bon	Une association d'endpoint nommé. Une politique le référence par `name`.
Une URL d'endpoint HTTPS	✅ Bon	Là 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 ; routez différentes politiques vers différentes URL.
`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'en utilisent pas de nommé. Voir l'endpoint default pour la façon dont 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, donc une valeur mal configurée signifie que les reports disparaissent 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 est une simple table name="url" par réponse, ce qui colle à la façon dont les politiques sont livrées (par réponse) et que les autres moteurs de navigateur ont une voie pour adopter. 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 erreur réseau ou une dépréciation autrement silencieuse en un signal que vous pouvez collecter, surveiller et sur lequel alerter. La protection vient de la politique ; ce header est la façon dont vous apprenez que la politique 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 résout 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 qui doit reporter, nommez un ou plusieurs endpoints, et référencez-les depuis chaque politique. Pour confirmer qu'un site en production est correctement câblé sans construire de récepteur, utilisez 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