# Reporting-Endpoints header (/fr/docs/web-security/reporting-api/headers/reporting-endpoints) `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)](/fr/docs/web-security/policies/content-security-policy), [COOP](/fr/docs/web-security/policies/cross-origin-opener-policy) et [COEP](/fr/docs/web-security/policies/cross-origin-embedder-policy) reprennent ce nom pour y acheminer leurs reports. C'est le remplaçant moderne du header historique [`Report-To`](/fr/docs/web-security/reporting-api/headers/report-to). ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" ``` ```http Content-Security-Policy: default-src 'self'; report-to csp-endpoint ``` ## Qu'est-ce que le header Reporting-Endpoints [#quest-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 [#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). | ```http Reporting-Endpoints: default="https://.report.centralcsp.com", csp-endpoint="https://.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](/fr/docs/web-security/reporting-api/concepts/default-endpoint) pour comprendre comment le repli est résolu. ## Valeurs non sûres à éviter [#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 [#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](/fr/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints). ## Ce contre quoi il protège [#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 [#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`](/fr/docs/web-security/reporting-api/headers/report-to). ## Risques d'une mauvaise configuration [#risques-dune-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 [#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). ```http Reporting-Endpoints: csp-endpoint="https://.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 [#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](/tools/reporting-api) ; pour collecter et agréger les reports sans monter de backend, pointez l'endpoint vers le [reporting CentralCSP](/fr/docs/platform/monitoring). ## Prise en charge par les navigateurs [#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. ## Voir aussi [#voir-aussi] * [Report-To header](/fr/docs/web-security/reporting-api/headers/report-to) * [Report-To vs Reporting-Endpoints](/fr/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints) * [Le format de livraison des reports](/fr/docs/web-security/reporting-api/concepts/report-delivery-format) * [Politiques](/fr/docs/web-security/policies) * [Où vont les reports du navigateur et comment les recevoir](/fr/blog/where-to-send-csp-reports) ## Sources [#sources] * [MDN, Reporting-Endpoints header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Reporting-Endpoints) * [W3C, Reporting API](https://www.w3.org/TR/reporting-1/) * [Chrome, migrate to Reporting API v1](https://developer.chrome.com/blog/reporting-api-migration)