# 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) référencent ce nom pour router 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 une politique fonctionnent donc toujours en paire. ## Valeurs et rôle de chacune [#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). | ```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'en utilisent pas de nommé. Voir [l'endpoint default](/fr/docs/web-security/reporting-api/concepts/default-endpoint) pour la façon dont 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, 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 [#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](/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 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 [#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 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 [#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 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](/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)