# Le header Reporting-Endpoints expliqué (/fr/blog/reporting-endpoints-header) Le header de réponse HTTP `Reporting-Endpoints` est la façon d'indiquer au navigateur où envoyer les rapports. Vous donnez un nom à chaque destination, puis vous pointez votre politique de sécurité du contenu (CSP) et vos autres politiques vers ce nom. Un seul header, un seul endroit pour déclarer chaque endpoint, et le navigateur assure la livraison. C'est la façon actuelle de câbler le reporting sur le web. Elle remplace l'ancien header `Report-To`, et elle fonctionne avec la directive CSP [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) pour collecter les rapports de violation, les avertissements de deprecation, les rapports d'intervention, et plus encore. Cet article est le guide de câblage pratique. Pour la référence de spec champ par champ, voir la [référence du header Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints). ## Ce que fait le header Reporting-Endpoints [#ce-que-fait-le-header-reporting-endpoints] Le header transporte une liste d'endpoints nommés. Chaque nom correspond à une seule URL vers laquelle le navigateur peut POST des rapports. Rien ne rapporte nulle part de soi-même : une politique doit référencer un nom d'endpoint avant que le navigateur ne lui envoie quoi que ce soit. Voici la plus petite mise en place qui collecte les violations CSP : ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" ``` ```http Content-Security-Policy: default-src 'self'; report-to csp-endpoint ``` La première ligne déclare un endpoint appelé `csp-endpoint`. La deuxième ligne est une CSP normale, et sa directive [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) nomme cet endpoint. Quand la politique bloque quelque chose, le navigateur envoie un rapport de violation à l'URL derrière `csp-endpoint`. ## Syntaxe du header [#syntaxe-du-header] Chaque entrée est `name="url"` : un nom d'endpoint, un signe égal, et l'URL sous forme de chaîne entre guillemets. Le navigateur résout l'URL par rapport à la réponse sur laquelle elle est arrivée. Vous pouvez déclarer plusieurs endpoints nommés dans un seul header, séparés par des virgules, et acheminer différents types de rapports vers eux par leur nom : ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com", permissions-endpoint="https://.report.centralcsp.com" ``` Puis une politique choisit le nom qu'elle veut : ```http Content-Security-Policy: default-src 'self'; report-to csp-endpoint ``` Quelques règles à connaître d'emblée : * Les URL d'endpoint doivent être potentiellement dignes de confiance, ce qui en pratique veut dire HTTPS. Un endpoint non sécurisé est silencieusement ignoré, pas signalé comme une erreur, donc une faute de frappe dans le schéma fait que les rapports partent discrètement dans le vide. * Un endpoint en v1 est une seule URL. Il n'y a ni pondération, ni priorité, ni liste de bascule, contrairement aux groupes `Report-To` plus anciens. * Les endpoints que vous déclarez s'appliquent à la ressource avec laquelle le header a été envoyé, pas à toute l'origine. ## L'endpoint default [#lendpoint-default] Certains types de rapports ne sont pas liés à un header qui nomme un endpoint. Les rapports de deprecation, d'intervention et de crash vont à un endpoint nommé `default` si vous en déclarez un : ```http Reporting-Endpoints: default="https://.report.centralcsp.com" ``` Malgré son nom, `default` n'est pas un repli pour les autres endpoints. C'est l'endpoint spécifique que ces types de rapports sans étiquette recherchent. Si vous ne déclarez pas d'endpoint `default`, le navigateur génère quand même ces rapports, mais il n'a nulle part où les envoyer, ils sont donc abandonnés. ## La directive CSP report-to [#la-directive-csp-report-to] La directive [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) est le côté CSP de tout cela. Sa valeur est un nom d'endpoint, et ce nom doit exister dans un header `Reporting-Endpoints` sur la même réponse. La directive elle-même ne porte aucune URL ; elle ne fait que référencer un nom que vous avez déclaré dans le header. ```http Content-Security-Policy: default-src 'self'; script-src 'self'; report-to csp-endpoint ``` La directive est en CSP Level 3 et fonctionne uniquement en header. Elle ne marche pas dans un élément ``, cette partie du reporting doit donc être définie comme un vrai header de réponse. ## report-to face à report-uri [#report-to-face-à-report-uri] La directive plus ancienne est [`report-uri`](/fr/docs/web-security/policies/content-security-policy/directives/report-uri), qui prend une URL directement au lieu d'un nom d'endpoint. Elle est dépréciée. Tout navigateur qui comprend `report-to` ignore entièrement `report-uri`. [report-uri vs report-to](/fr/blog/report-uri-vs-report-to) compare les deux directives en détail. Pendant la transition, vous pouvez spécifier les deux. Le navigateur utilise celle qu'il prend en charge et ignore l'autre, vous gardez donc les rapports qui affluent de chaque visiteur : ```http Content-Security-Policy: default-src 'self'; report-uri https://.report.centralcsp.com; report-to csp-endpoint ``` Un navigateur avec la prise en charge de `report-to` utilise le nom d'endpoint et ignore l'URL de `report-uri`. Un navigateur sans elle se rabat sur `report-uri`. Associez cela au header `Reporting-Endpoints` correspondant pour que le nom d'endpoint se résolve. ## Où se place Report-To aujourd'hui [#où-se-place-report-to-aujourdhui] Le header `Report-To` est le prédécesseur de `Reporting-Endpoints`. Il est à la fois déprécié et non standard, et `Reporting-Endpoints` le remplace pour tout nouveau travail. Voir la [référence du header Report-To](/fr/docs/web-security/policies/content-security-policy/directives/report-to) pour son histoire, et [Report-To vs Reporting-Endpoints](/fr/blog/report-to-vs-reporting-endpoints) pour la migration en détail. Une exception pratique : [Network Error Logging (NEL)](/fr/blog/what-is-nel-network-error-logging) s'appuie encore sur le header hérité `Report-To` et n'est pas couvert par `Reporting-Endpoints` v1. Si vous collectez des rapports NEL, vous continuez d'envoyer `Report-To` pour ce cas tout en utilisant `Reporting-Endpoints` pour tout le reste. ## Prise en charge des navigateurs [#prise-en-charge-des-navigateurs] `Reporting-Endpoints` a atteint Baseline en 2024 et est largement pris en charge par les navigateurs actuels. La directive CSP `report-to` est présente dans Chromium depuis des années ; son jalon Baseline multi-navigateurs arrive en 2026 à mesure que les moteurs restants rattrapent leur retard. Pour les nouveaux sites, écrivez `Reporting-Endpoints` plus `report-to`, et n'ajoutez `report-uri` que si vous devez encore couvrir des clients plus anciens pendant une transition. ## Testez avant de faire confiance [#testez-avant-de-faire-confiance] Un header à défaillance silencieuse récompense une vérification rapide. Le moyen le plus rapide de confirmer que votre configuration s'analyse et se résout est le [vérificateur Reporting API](/tools/reporting-api), qui lit vos headers de réponse en direct et vous dit si les noms d'endpoints et les URL correspondent. Quand vous êtes prêt à démarrer en mode sûr, envoyez d'abord la politique comme un [header Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only). Le navigateur rapporte ce que la politique bloquerait sans l'appliquer, vous ajustez donc face au trafic réel avant que quoi que ce soit ne casse. Pour le workflow complet de reporting, y compris à quoi ressemble un rapport de violation, voir [Démarrer avec le reporting CSP](/fr/blog/get-started-csp-reporting). Une fois les rapports arrivés, [CentralCSP](/platform/csp-builder) les collecte en un seul endroit, groupe le bruit, et transforme les contenus bruts en quelque chose sur quoi agir. Vous pouvez [démarrer gratuitement](/register) et pointer votre header `Reporting-Endpoints` vers un endpoint CentralCSP pour voir de vrais rapports en quelques minutes. Une vérification de configuration confirmant l'arrivée des premiers rapports navigateur ## Articles liés [#articles-liés] * [Démarrer avec le reporting CSP](/fr/blog/get-started-csp-reporting) * [CSP enforce vs report-only](/fr/blog/csp-enforce-vs-report-only) ## Sources [#sources] * [W3C, Reporting API](https://www.w3.org/TR/reporting-1/) * [RFC 8941, Structured Field Values for HTTP](https://www.rfc-editor.org/rfc/rfc8941) * [MDN, Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Reporting-Endpoints)