# Alternatives à Report URI pour le reporting CSP (/fr/blog/report-uri-alternatives) Report URI collecte les rapports CSP, et il s'arrête là. S'il vous faut un vrai inventaire des scripts, des alertes qui atteignent l'équipe, des preuves PCI DSS et une interface que l'on ouvre volontiers, il vous faut une plateforme de sécurité client-side plutôt qu'un collecteur. Nous développons CentralCSP, lisez donc ceci comme notre point de vue. Cet article liste ce qu'il faut chercher, mesure CentralCSP à cette aune, puis passe brièvement sur Report URI, URIports, csper et Sentry, avec un tableau et un chemin de migration. Pour le voir sur votre propre trafic, [démarrez un essai gratuit](/register), ajoutez un header, et la [vue d'ensemble du monitoring](/platform/monitoring) affiche chaque type de rapport à son arrivée. ## Ce dont une équipe sécurité a besoin dans un outil de reporting CSP [#ce-dont-une-équipe-sécurité-a-besoin-dans-un-outil-de-reporting-csp] Tous les outils de cette page reçoivent un rapport de violation. La différence se joue ensuite, et six critères séparent un collecteur d'une plateforme de sécurité client-side. 1. **Un chemin vers l'enforcement.** Des rapports groupés par directive et origine, le bruit des extensions filtré, et la politique suivie dans le temps, pour qu'un déploiement en report-only aboutisse à un header appliqué plutôt qu'à un log que personne ne lit. 2. **Inventaire des scripts et preuves PCI DSS.** Le reporting de hash CSP ([`'report-sha256'`](/fr/docs/web-security/policies/content-security-policy/values/report-sha-keyword) et le rapport [`csp-hash`](/fr/docs/web-security/reporting-api/reports/csp-hash)) vous dit quels scripts se sont réellement exécutés sur chaque page. Un outil de sécurité en fait un inventaire avec des décisions d'autorisation et des preuves exportables pour les exigences 6.4.3 et 11.6.1 de PCI DSS v4. Il doit aussi dire quelle bibliothèque et quelle version se cache derrière chaque script, et si une CVE connue s'applique. 3. **Des alertes là où l'équipe travaille.** Un nouveau script sur la page de paiement doit atteindre Slack, Teams ou un webhook en quelques minutes. 4. **Hébergement UE et rétention fixe.** Les rapports contiennent des URL de pages, des URL bloquées et des extraits de scripts, donc leur lieu et leur durée de stockage sont une question de protection des données. 5. **Accès API et MCP.** Une API REST pour vos propres outils, et un serveur MCP pour qu'un assistant IA interroge directement les violations et l'inventaire. 6. **Remédiation des constats des agences de notation.** [BitSight](/fr/blog/fix-bitsight-csp-findings), [SecurityScorecard](/fr/blog/fix-securityscorecard-csp-findings) et RiskRecon notent votre CSP et vos security headers depuis l'extérieur. L'outil doit scanner ce que votre serveur envoie et piloter la correction, pas seulement recevoir ce que le navigateur rapporte. ## CentralCSP [#centralcsp] CentralCSP est une plateforme de sécurité client-side construite sur le [Reporting API](/fr/docs/web-security/reporting-api) du navigateur. Vous connectez un site avec un seul header [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) (plus [`Report-To`](/fr/docs/web-security/reporting-api/headers/report-to) pour le [Network Error Logging](/fr/docs/web-security/policies/network-error-logging), qui ne se livre que par le header hérité). Pas d'agent, pas de proxy, pas de snippet JavaScript. Le navigateur continue d'appliquer la politique ; CentralCSP transforme ce qu'il rapporte en décisions. Face aux six critères : * **Chemin vers l'enforcement.** Les violations sont groupées par directive et origine, le bruit des extensions est mis de côté, et la politique est suivie du report-only à l'enforcement. Le même endpoint ingère les 12 types de rapports navigateur (violations CSP, [hashes CSP](/fr/docs/platform/monitoring/script-hash), NEL, dépréciation, intervention, crash, COOP, COEP, Permissions-Policy, Document-Policy, Integrity-Policy et Connection-Allowlist). La CSP a l'ensemble de fonctionnalités le plus complet ; les autres types sont ingérés et affichés aujourd'hui, avec des fonctionnalités plus poussées sur la feuille de route. * **Inventaire des scripts et PCI DSS.** Le reporting de hash construit un [inventaire des scripts](/fr/docs/platform/features/script-inventory) de ce qui s'exécute sur chaque page, et le [module PCI DSS](/fr/docs/platform/features/pci-dss) le transforme en décisions de revue et en dossier de preuves exportable. CentralCSP vous aide à répondre aux exigences 6.4.3 et 11.6.1 ; c'est votre évaluateur qui valide. L'[inventaire des technologies](/fr/docs/platform/features/technologies) nomme la bibliothèque et la version derrière chaque script et signale les CVE connues. * **Alertes.** [Slack, Microsoft Teams, Google Chat, Telegram, email et webhooks](/fr/docs/platform/features/alerting/channels). * **Hébergement UE.** Les données de rapports et des clients sont hébergées en Europe, chez OVH, avec une [rétention fixe de 90 jours](/fr/docs/platform/security/data-retention). La plateforme fait l'objet de tests d'intrusion indépendants et prend en charge le SSO, le RBAC, la MFA et un journal d'audit. Stripe gère les paiements depuis les États-Unis, donc l'engagement de résidence porte sur les données de rapports et des clients. * **API et MCP.** L'[API REST](/fr/docs/api-mcp/api) et le [serveur MCP](/fr/docs/api-mcp/mcp) intégré exposent les mêmes données aux scripts et aux clients IA. * **Constats des agences de notation.** Le [scanner CSP](/tools/csp-scanner), le [scanner de security headers](/tools/security-headers) et le [vérificateur Reporting API](/tools/reporting-api), gratuits, lisent ce que votre serveur envoie aujourd'hui ; le tableau de bord porte ensuite la correction jusqu'au header appliqué qu'une agence de notation évalue. Elle est conçue pour les entreprises dotées d'une équipe sécurité et pour les structures plus petites qui prennent la sécurité client-side au sérieux. Le détail des offres est sur la [page tarifaire](/pricing). ## Report URI [#report-uri] Report URI est la génération précédente des outils de reporting CSP, pensée d'abord pour la collecte. Il accepte les violations CSP, le NEL et les autres types de rapports du Reporting API, et il les stocke. C'est tout le modèle : il tient une liste de scripts plutôt qu'un flux de revue avec justifications écrites, les alertes couvrent les événements que le service documente, et l'interface est organisée autour des volumes de rapports plutôt qu'autour des décisions. La tarification est par domaine, et les fonctions de sécurité existantes sont réservées aux paliers supérieurs. Il convient encore à un domaine unique dont personne n'a la charge du risque client-side. ## URIports, csper, Sentry et l'auto-hébergement [#uriports-csper-sentry-et-lauto-hébergement] **URIports** est un service néerlandais né du reporting DMARC. Il est hébergé dans l'UE, accepte les types de rapports navigateur, et alerte par email, webhook et Telegram. Il n'y a ni inventaire des scripts, ni preuves PCI DSS, ni serveur MCP. Il convient quand l'authentification email est la moitié de votre problème. **csper** est un outil pour développeurs construit autour de la seule CSP, avec un générateur de politique, un évaluateur, une extension de navigateur et des rapports classés par type. Il ne couvre pas les autres types du Reporting API et n'a ni inventaire des scripts ni preuves PCI DSS. Il convient à un développeur indépendant qui veut essayer la CSP sur un projet personnel. **Sentry** peut recevoir les violations CSP comme des événements à côté de vos erreurs JavaScript si vous l'utilisez déjà. Pas de regroupement propre à la CSP à l'échelle d'un site, pas d'inventaire, pas d'autres types de rapports. Convient à une équipe applicative ; ne remplace pas un endpoint dédié dès que la sécurité ou la conformité prend possession des rapports. **L'auto-hébergement** est tentant parce qu'accepter le POST tient en quelques lignes de code, comme le montre l'article [où vont les rapports CSP](/fr/blog/where-to-send-csp-reports). Le regroupement, la déduplication, le filtrage du bruit, la rétention, les alertes, une interface et les autres formes de payload sont le vrai coût, et la plupart des collecteurs maison cessent d'être maintenus une fois leur auteur parti. ## Tableau comparatif [#tableau-comparatif] ✅ couvert, 🟠 partiel, ❌ absent, d'après la documentation publique de chaque éditeur en septembre 2026. | | CentralCSP | Report URI | URIports | csper | Sentry | | ------------------------ | :----------------: | :--------------: | :---------------: | :---------------: | :---------------: | | Rapports CSP | ✅ | ✅ | ✅ | ✅ | ✅ | | Autres types de rapports | ✅ | ✅ | ✅ | ❌ | ❌ | | NEL | ✅ | ✅ | ✅ | ❌ | ❌ | | Inventaire des scripts | ✅ Complet | 🟠 Liste seule | ❌ | ❌ | ❌ | | Détection techno et CVE | ✅ | ❌ | ❌ | ❌ | ❌ | | Preuves PCI DSS | ✅ Flux complet | 🟠 Liste seule | ❌ | ❌ | ❌ | | Alertes | ✅ Règles, 6 canaux | 🟠 Limitées | 🟠 Email, webhook | 🟠 Alertes de pic | 🟠 Alertes Sentry | | Scan des headers | ✅ | ❌ | ❌ | 🟠 | ❌ | | API REST | ✅ Complet | 🟠 Lecture seule | 🟠 Limité | ✅ | ✅ | | Serveur MCP | ✅ Complet | 🟠 Limité | ❌ | ❌ | 🟠 | | Hébergement UE | ✅ OVH | 🟠 | ✅ | ❌ | 🟠 | Les noms de produits appartiennent à leurs propriétaires. La comparaison repose sur la documentation publique de chaque éditeur au moment de la rédaction. ## Comment migrer depuis Report URI [#comment-migrer-depuis-report-uri] Vous n'avez pas besoin d'un jour de bascule. Un navigateur qui comprend [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) ignore [`report-uri`](/fr/docs/web-security/policies/content-security-policy/directives/report-uri) quand les deux sont présents, donc les deux endpoints ne reçoivent jamais de doublons et vous pouvez faire tourner les deux pendant une semaine. 1. Créez un site web dans CentralCSP et copiez son endpoint. 2. Ajoutez un header `Reporting-Endpoints` qui le nomme, et une directive `report-to` à la politique, en gardant le `report-uri` existant. 3. Comparez les deux tableaux de bord pendant une semaine ; les volumes concordent une fois le regroupement et le filtrage des extensions pris en compte. 4. Retirez l'ancienne directive `report-uri` et résiliez l'ancien abonnement. ```http Reporting-Endpoints: csp-endpoint="https://MyEndpoint.report.centralcsp.com" ``` ```http Content-Security-Policy: default-src 'self'; script-src 'nonce-{RANDOM}' 'strict-dynamic'; object-src 'none'; base-uri 'none'; report-uri https://old-collector.example/r/d/csp/enforce; report-to csp-endpoint ``` Pour les autres types de rapports, ajoutez un endpoint `default` au même header `Reporting-Endpoints`. Le NEL est l'exception et exige un header `Report-To` ; la page [Report-To vs Reporting-Endpoints](/fr/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints) montre les deux côte à côte. ## Lequel choisir [#lequel-choisir] N'importe quel outil ci-dessus stockera vos rapports CSP. Si vous êtes responsable de la sécurité client-side et qu'il vous faut un inventaire des scripts, des preuves PCI DSS, des alertes, un hébergement UE et une API avec serveur MCP, [démarrez un essai gratuit](/register), pointez `report-to` vers votre endpoint, et regardez les premiers rapports arriver dans la [vue d'ensemble du monitoring](/platform/monitoring). ## Sources [#sources] * [MDN, Reporting API](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API) * [W3C, Reporting API](https://www.w3.org/TR/reporting-1/) * [PCI Security Standards Council, bibliothèque de documents](https://www.pcisecuritystandards.org/document_library/) ## Articles liés [#articles-liés] * [report-uri vs report-to, et comment migrer](/fr/blog/report-uri-vs-report-to) * [Où vont les rapports CSP du navigateur et comment les recevoir](/fr/blog/where-to-send-csp-reports) * [Démarrer avec le reporting CSP](/fr/blog/get-started-csp-reporting)