--- title: "Vérificateur Reporting API gratuit - Reporting-Endpoints" description: "Vérificateur Reporting API gratuit : Reporting-Endpoints, Report-To, report-uri et NEL d'une URL, et les rapports que le navigateur abandonne en silence." url: "https://centralcsp.com/fr/tools/reporting-api/" lang: "fr" --- Outils # Vérificateur Reporting API Entrez une URL et voyez où partent réellement ses rapports navigateur : Reporting-Endpoints, Report-To, le report-uri CSP de repli et NEL, fonctionnalité par fonctionnalité. ### Vérifier une URL Inspectez la configuration de reporting d'un site : points de collecte, reporting par fonctionnalité et politiques. Suivre les redirections Scanner la configuration de reporting Besoin d'auditer plus que le reporting ? [Lancer le scanner d'en-têtes de sécurité](https://centralcsp.com/fr/tools/security-headers/) Exemple de résultat ## À quoi ressemble une vérification Quels endpoints sont déclarés, quelles fonctionnalités leur envoient réellement des rapports, et quoi corriger en premier. Un Aucun rouge signifie que le navigateur génère des rapports et les perd tous silencieusement. ### Points de collecte Points de collecte déclarés par le site, et s'ils sont utilisés. | Point de collecte | URL | Statut | Déclaré dans | | --- | --- | --- | --- | | csp-endpoint | https://k4x2c9wq.report.centralcsp.com | Utilisé | reporting-endpoints | | default | https://f8g1n3ap.report.centralcsp.com | Utilisé | reporting-endpoints | | legacy-analytics | https://a1b7d2xe.report.centralcsp.com | Inutilisé | report-to | * * * ### Fonctionnalités Statut de reporting de chaque fonctionnalité de sécurité et où ses rapports sont envoyés. | Fonctionnalité | Présent | Mode | Point de collecte | URLs de reporting | | --- | --- | --- | --- | --- | | Content Security Policy[](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy) | Présent | Appliqué | csp-endpoint | https://k4x2c9wq.report.centralcsp.com | | Cross-Origin-Opener-Policy[](https://centralcsp.com/fr/docs/web-security/policies/cross-origin-opener-policy) | Présent | Report-Only | coop | Aucun | | Permissions Policy[](https://centralcsp.com/fr/docs/web-security/policies/permissions-policy) | Présent | Appliqué | défaut (repli) | https://f8g1n3ap.report.centralcsp.com | | Network Error Logging[](https://centralcsp.com/fr/docs/web-security/policies/network-error-logging) | Absent | | | | * * * ### Constats et recommandations Problèmes et recommandations de qualité pour la configuration de reporting. ### Les rapports COOP sont abandonnés en silence Cross-Origin-Opener-Policy-Report-Only nomme l'endpoint coop, mais aucun en-tête Reporting-Endpoints ou Report-To ne déclare d'endpoint portant ce nom. Élevé Sécurité Élevé Sécurité Recommandation Ajoutez coop="https://.report.centralcsp.com" à l'en-tête Reporting-Endpoints, ou modifiez la directive report-to pour qu'elle pointe vers un endpoint déclaré. Impact Le navigateur génère un rapport pour chaque violation COOP puis le jette : la politique paraît branchée alors que rien n'arrive jamais. ### L'endpoint legacy-analytics est déclaré mais jamais utilisé L'en-tête Report-To déclare le groupe legacy-analytics, mais aucune fonctionnalité de la page ne lui envoie de rapports. Moyen Qualité Moyen Qualité Recommandation Supprimez le groupe legacy-analytics de l'en-tête Report-To, ou faites-y pointer une fonctionnalité s'il est encore nécessaire. Impact Les déclarations inutilisées rendent une configuration de reporting plus difficile à auditer et signalent en général une configuration qui a dérivé de ce que le site envoie réellement. Guide ## Comprendre le reporting navigateur La Reporting API est le mécanisme par lequel le navigateur collecte les violations de politique, les erreurs réseau, les dépréciations et les crashs, puis les livre hors bande à un endpoint que vous déclarez dans un en-tête de réponse. Le navigateur vous signale ce que votre Content Security Policy bloque, une requête qui échoue ou une page qui utilise une API dépréciée. Mais il ne le fait que si vos en-têtes indiquent où envoyer le rapport, et la plupart des sites ne l'indiquent jamais. ### Ce que le vérificateur examine Il répond à trois questions sur n'importe quelle URL : où avez-vous dit aux navigateurs d'envoyer leurs rapports, quelles fonctionnalités de sécurité sont réellement câblées vers ces endpoints, et quels rapports sont générés puis jetés. Il ne lit que vos en-têtes de réponse, car c'est aussi tout ce qu'un navigateur lit : pas d'agent, pas de JavaScript, rien à installer. ### Reporting-Endpoints ou Report-To ? Deux en-têtes peuvent faire le travail, et l'un des deux vit en sursis. Reporting-Endpoints est le standard actuel : une ligne de paires nom-URL. Report-To est son prédécesseur déprécié, et la seule raison pour laquelle il refuse de mourir est Network Error Logging, qui l'exige encore. Si vous ajoutez le reporting aujourd'hui, déclarez vos endpoints dans Reporting-Endpoints. Les deux sont couverts en profondeur dans le [guide Reporting-Endpoints](https://centralcsp.com/fr/docs/web-security/reporting-api/headers/reporting-endpoints) et le [guide Report-To](https://centralcsp.com/fr/docs/web-security/reporting-api/headers/report-to). ``` Reporting-Endpoints: default="https://.report.centralcsp.com", csp-endpoint="https://.report.centralcsp.com" Report-To: {"group":"default","max_age":86400,"endpoints":[{"url":"https://.report.centralcsp.com"}]} ``` ### Reporting-Endpoints, Report-To, report-to, report-uri Quatre noms, deux en-têtes et deux directives CSP. Voici le tableau que l'on vient réellement chercher. Les deux en-têtes de reporting et les deux directives CSP de reporting comparés | Nom | Ce que c'est | Statut | Quand vous en avez encore besoin | | --- | --- | --- | --- | | `Reporting-Endpoints` | En-tête de réponse nommant les endpoints par paires nom-URL | À jour | Toujours, pour toute nouvelle configuration | | `Report-To` | En-tête de réponse déclarant des groupes d'endpoints en JSON | Déprécié, mais requis pour NEL | Seulement si vous collectez le Network Error Logging | | `report-to` | Directive CSP pointant vers un nom d'endpoint déclaré dans un en-tête | À jour | Toujours, pour router les violations CSP vers un endpoint | | `report-uri` | Directive CSP nommant directement une URL, sans en-tête requis | Déprécié | Plus nécessaire : report-to et Reporting-Endpoints la remplacent | ### Brancher les rapports de violation CSP avec report-to Le déploiement de CSP le plus sûr commence par des rapports, pas par des règles. Servez la politique en Content-Security-Policy-Report-Only avec une directive report-to qui pointe vers un endpoint déclaré dans Reporting-Endpoints. Les navigateurs vous disent alors exactement ce que la politique aurait cassé, et vous la durcissez avant qu'un seul visiteur ne soit affecté. La directive report-uri, dépréciée, ne vaut plus la peine d'être ajoutée à une nouvelle politique : report-to et Reporting-Endpoints couvrent à eux seuls les rapports de violation CSP. Pour les détails, consultez la [Présentation de Content-Security-Policy](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy) et le [guide du rapport de violation CSP](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/csp-violation). ``` Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint ``` ### NEL, l'exception qui exige encore Report-To Certains échecs n'atteignent jamais votre serveur : un DNS qui ne résout pas, un TLS qui n'aboutit pas, des connexions qui meurent en route. Network Error Logging est la façon dont les navigateurs les rapportent, et comme la visite échouée ne livre aucun en-tête, le navigateur doit se souvenir de votre configuration depuis une visite réussie antérieure. C'est pourquoi NEL a encore besoin de l'ancien en-tête Report-To, et pourquoi Reporting-Endpoints ne peut pas le remplacer. Chromium uniquement. Syntaxe complète dans le [guide Network Error Logging](https://centralcsp.com/fr/docs/web-security/policies/network-error-logging). ``` Report-To: {"group":"network-errors","max_age":2592000,"endpoints":[{"url":"https://.report.centralcsp.com"}]} NEL: {"report_to":"network-errors","max_age":2592000} ``` ### Quand les rapports n'arrivent pas Six causes couvrent la quasi-totalité des endpoints silencieux. - **Une page servie en http://.** La Reporting API ne fonctionne que dans un contexte sécurisé : une page qui n'est pas servie en HTTPS ne génère aucun rapport, quels que soient ses en-têtes. - **Un nom d'endpoint que rien ne déclare.** Une directive report-to pointe vers un endpoint qu'aucun en-tête Reporting-Endpoints ou Report-To ne déclare : le navigateur génère le rapport puis l'abandonne. - **Un endpoint en http://.** Les navigateurs l'ignorent, sans erreur ni avertissement en console. - **Le mauvais type de contenu.** L'endpoint doit accepter les requêtes POST en application/reports+json, ou en application/csp-report pour l'ancien format report-uri. - **Une réponse autre qu'un code 2xx.** Tout autre code et le navigateur considère la livraison comme échouée. - **Le délai de regroupement.** Celui que l'on prend le plus souvent pour une panne. Les navigateurs mettent les rapports en file et les envoient un peu après le chargement de page qui les a produits : un endpoint qui semble mort trente secondes après un test n'a peut-être simplement pas eu le temps. Si vous voulez voir les rapports avant même d'avoir branché un endpoint, une page peut lire les siens avec ReportingObserver en JavaScript : c'est un bon moyen de confirmer que le navigateur génère bien ce que vous attendez. ### Comment lire vos résultats Les résultats sont pensés pour être simples : ils vous montrent comment votre reporting est configuré et signalent tout ce qui le casserait. Un endpoint référencé qu'aucun en-tête ne déclare ? Signalé. Un endpoint déclaré vers lequel rien n'envoie ? Signalé. Une politique qui ne rapporte nulle part ? Signalée aussi, avec le correctif juste à côté. Corrigez ce qui est signalé, relancez la vérification, et vos rapports continuent d'arriver. Pour aller plus loin - [L'en-tête Reporting-Endpoints](https://centralcsp.com/fr/docs/web-security/reporting-api/headers/reporting-endpoints) - [L'en-tête Report-To](https://centralcsp.com/fr/docs/web-security/reporting-api/headers/report-to) - [Network Error Logging (NEL)](https://centralcsp.com/fr/docs/web-security/policies/network-error-logging) - [Les rapports de violation CSP](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/csp-violation) - [Report-To ou Reporting-Endpoints, le comparatif](https://centralcsp.com/fr/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints) - [L'endpoint de reporting par défaut](https://centralcsp.com/fr/docs/web-security/reporting-api/concepts/default-endpoint) - [Le format d'envoi application/reports+json](https://centralcsp.com/fr/docs/web-security/reporting-api/concepts/report-delivery-format) - [Mettre en place la Reporting API du navigateur](https://centralcsp.com/fr/blog/how-to-set-up-the-reporting-api) Plus d'outils gratuits ## Poursuivez l'audit avec les autres outils gratuits Chaque outil est gratuit, fonctionne sans compte et note avec la même échelle de sévérité. ### Scanner CSP Récupérez la Content-Security-Policy réellement servie par une URL et notez-la face aux contournements connus, aux sources joker et aux directives manquantes. - Constats au niveau des directives - Lien de résultats partageable [Lancer le scanner CSP](https://centralcsp.com/fr/tools/csp-scanner/) ### Évaluateur CSP Collez une politique pas encore déployée et obtenez la même notation et les mêmes constats qu'un scan en ligne, sans URL. - Auditez avant de déployer - Même moteur de notation [Évaluer une politique dans l'évaluateur CSP](https://centralcsp.com/fr/tools/csp-evaluator/) ### Scanner d'en-têtes de sécurité Notez chaque en-tête de sécurité envoyé par une URL, de HSTS à Permissions-Policy, avec chaque constat expliqué et priorisé. - Tous les en-têtes, une seule note - Correctifs classés par impact [Scanner vos en-têtes de sécurité](https://centralcsp.com/fr/tools/security-headers/) ### Générateur de hash SRI Transformez l'URL d'un script ou d'un CSS servi par un CDN en hash Subresource Integrity, avec une balise prête à coller et une vérification CORS. - SHA-256, 384 et 512 - CORS vérifié pour vous [Générer un hash SRI](https://centralcsp.com/fr/tools/sri-hash/) ### Générateur de hash CSP Transformez un script ou un style inline en hash qui l'autorise sous une politique stricte, directement dans votre navigateur. - Fonctionne entièrement côté client - SHA-256, 384 et 512 [Générer un hash CSP](https://centralcsp.com/fr/tools/csp-hash/) ### Comparateur de sites Situez votre score : votre site à côté de la moyenne du jeu de données et des sites les mieux configurés de l'année, contrôle par contrôle. - Références publiées et vérifiables - Vue radar par catégorie [Comparez votre site aux meilleurs](https://centralcsp.com/fr/tools/compare/) FAQ ## Questions fréquentes Endpoints, en-têtes et rapports manquants : les réponses. ### Qu'est-ce que l'en-tête Reporting-Endpoints ? Reporting-Endpoints est un en-tête de réponse HTTP qui nomme les URL auxquelles un navigateur envoie ses rapports, sous forme de simples paires nom-URL : Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com". Des fonctionnalités comme la CSP référencent ensuite un nom via leur directive report-to. C'est le standard actuel de la Reporting API du W3C, qui remplace l'ancien en-tête Report-To. ### L'en-tête Report-To est-il déprécié ? Oui. Report-To appartient à la première version de la Reporting API et a été remplacé par Reporting-Endpoints, dont la syntaxe est plus simple et sans durée de vie en cache. Il reste une raison de le conserver : Network Error Logging ne fonctionne qu'à travers un groupe Report-To, donc un site qui veut des rapports NEL continue d'envoyer les deux en-têtes. Pour tout le reste, déclarez vos endpoints dans Reporting-Endpoints. ### Quels navigateurs prennent en charge Reporting-Endpoints ? Reporting-Endpoints et la directive report-to sont le standard actuel et ce qu'une nouvelle configuration doit envoyer. La couverture n'est pas uniforme sur tous les navigateurs, mais le repli est le silence, pas la casse : un navigateur qui ne comprend pas l'en-tête n'envoie simplement rien. Le Network Error Logging est la seule pièce réservée à Chromium, et la seule raison de conserver l'ancien en-tête Report-To à côté. ### Peut-on définir Reporting-Endpoints dans une balise meta ? Non. Reporting-Endpoints est un en-tête de réponse et n'a pas d'équivalent en balise meta. Une Content-Security-Policy livrée via une balise meta http-equiv ne peut pas non plus porter de directives de reporting : un site qui ne peut définir une politique que dans le HTML ne peut donc collecter aucun rapport. C'est une raison de plus pour laquelle les rapports manquent sur les plateformes où vous ne maîtrisez pas les en-têtes de réponse. ### Ai-je encore besoin de report-uri dans ma CSP ? Non. Une directive report-to qui pointe vers un endpoint déclaré dans Reporting-Endpoints suffit à une politique pour ses rapports de violation CSP, et report-uri est déprécié. L'ajouter à une nouvelle politique n'apporte rien et laisse une seconde destination à maintenir. Si une politique existante en porte encore un, vous pouvez le retirer dès que ce vérificateur confirme que votre endpoint report-to reçoit bien les rapports. ### Pourquoi mon endpoint de reporting ne reçoit-il aucun rapport ? La cause la plus fréquente est une référence orpheline : une directive report-to nomme un endpoint qu'aucun en-tête Reporting-Endpoints ou Report-To ne déclare, et le navigateur abandonne alors chaque rapport qu'il génère. Vérifiez aussi que l'endpoint accepte les requêtes POST avec le type de contenu application/reports+json (application/csp-report pour l'ancien report-uri), renvoie un code 2xx et est servi en HTTPS. Et soyez patient : les navigateurs regroupent les rapports et les envoient un peu après le chargement de la page déclencheuse. Ce vérificateur signale directement les références orphelines et les endpoints inutilisés. ### Quels types de rapports un navigateur peut-il envoyer ? Via la Reporting API : violations CSP, violations COOP et COEP, violations Permissions-Policy et Document-Policy, violations d'intégrité, avertissements de dépréciation, interventions du navigateur et crashs du moteur de rendu. Les rapports de dépréciation, d'intervention et de crash ne demandent aucune directive dédiée ; ils vont à l'endpoint par défaut, celui que vous déclarez sous le nom default, qui récupère tous les types de rapports sans cible explicite. Les erreurs réseau (NEL) sont à part : Chromium uniquement, configurées par l'en-tête NEL, livrées via un groupe Report-To. ## Endpoint vérifié. Collectez-y maintenant de vrais rapports. CentralCSP vous fournit un endpoint de reporting managé qui accepte toutes les générations : report-uri, Report-To et Reporting-Endpoints sur la même URL. Les rapports arrivent dédupliqués, regroupés et alertés dans Slack ou Teams. Ajoutez un en-tête, sans changer votre code. [Commencer avec CentralCSP](https://app.centralcsp.com) [Collecter les rapports que vous venez de vérifier](https://centralcsp.com/fr/platform/monitoring/) --- Disponible en : [en](https://centralcsp.com/en/tools/reporting-api/), [fr](https://centralcsp.com/fr/tools/reporting-api/)