--- title: "Surveillance des violations CSP et rapports navigateur" description: "Un seul endpoint collecte les 12 types de rapports navigateur : violations CSP, hash de scripts, NEL, crashs. Dédupliqués et hébergés en France." url: "https://centralcsp.com/fr/platform/monitoring/" lang: "fr" --- Surveillance # Tous les signaux du navigateur, au même endroit. Scripts bloqués, connexions échouées, onglets plantés : les navigateurs les rapportent pendant que vos utilisateurs naviguent. CentralCSP collecte tout avec un seul en-tête de réponse. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Vérifiez ce que votre site collecte](https://centralcsp.com/fr/tools/reporting-api/) Comment ça marche ## De l'en-tête de réponse aux alertes dans vos canaux existants. Un endpoint de reporting est une URL à laquelle le navigateur envoie ses rapports en POST, déclarée dans un en-tête de réponse Reporting-Endpoints. La surveillance des violations CSP consiste à collecter ces rapports issus du trafic réel, à les dédupliquer et à les lire, que votre politique soit en report-only ou bloquante. 1. 01 - Collecter ### Déployez un en-tête Ajoutez Reporting-Endpoints au niveau de votre CDN, proxy ou framework. La directive historique report-uri atterrit sur le même endpoint. 2. 02 - Traiter ### Collecté, dédupliqué, classé Les navigateurs envoient les rapports en arrière-plan : vos visiteurs ne sentent rien. Chaque rapport est conservé ; les doublons se regroupent et les faux positifs d'extensions sont signalés. 3. 03 - Agir ### Observer, alerter, exporter Filtrez le flux en direct, acheminez les alertes vers vos canaux, récupérez le JSON brut via l'API. Mise en place ## Votre endpoint de reporting est à un en-tête de réponse. Ajoutez Reporting-Endpoints à vos réponses et les navigateurs commencent à livrer leurs rapports à votre endpoint. en-tête de réponse Reporting-Endpoints : default= "https://MyEndpoint.report.centralcsp.com" Vous avez déjà une CSP ? Pointez son report-to vers le même endpoint et chaque violation y arrive aussi. Les anciens payloads report-uri sont acceptés aussi : changer de collecteur tient à la même modification d'une ligne. 1. ### Ajoutez votre site Créez le site dans votre tableau de bord et copiez son endpoint de reporting managé. 2. ### Déployez l'en-tête Déployez depuis votre edge ou votre application. Les rapports affluent immédiatement depuis les navigateurs de vrais visiteurs. 3. ### Routez le signal Suivez le tableau de bord en direct, branchez les alertes sur vos canaux, récupérez tout via l'API. Vérifiez votre configuration ## Votre site rapporte-t-il déjà ? Vérifier ma config Gratuit, sans compte. Les résultats arrivent sur une page partageable. Ce que le scan vérifie - Configuration des politiques : quels types de rapports vos en-têtes demandent - Configuration de l'endpoint : où partent les rapports et s'il répond - Mauvaises configurations : ce qui est perdu silencieusement aujourd'hui Agrégation ## Un million de rapports deviennent une courte liste de problèmes. Les rapports bruts restent stockés et interrogeables, mais vous travaillez sur l'agrégat : groupé, dédupliqué et classé pour que le vrai problème remonte en premier. - Voyez la tendance, repérez le changement - Agrégé : un problème, une ligne Ce que nous collectons ## Douze types de rapports. Trois raisons de les vouloir. La plupart des outils s'arrêtent aux violations CSP. Les navigateurs peuvent rapporter bien plus, et chaque type ci-dessous atterrit sur le même endpoint, parsé et consultable. ### Signaux d'attaque Les rapports qui détectent le code injecté, les fichiers altérés et les données qui quittent la page. `csp-violation` Violations CSP Une ressource s'est chargée, ou a tenté de le faire, contre votre Content Security Policy. Fonctionne en mode strict comme en report-only. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/csp-violation) `csp-hash` Hachages de scripts Le hash de chaque script que vos pages exécutent. Votre inventaire de scripts, et votre preuve PCI DSS 6.4.3, issus du trafic réel. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/csp-hash) `integrity-violation` Violations d'intégrité Un fichier ne correspond plus à son hash Subresource Integrity. Soit votre build l'a modifié, soit quelqu'un d'autre. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/integrity-violation) `connection-allowlist` Violations de Connection Allowlist Une connexion sortante a quitté la page vers une origine jamais déclarée. C'est ainsi qu'une exfiltration se remarque. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/connection-allowlist) ### Les échecs que votre serveur ne consigne jamais Ils surviennent avant que la requête ne vous atteigne, ou après la mort de la page. Seul le navigateur peut les rapporter. `network-error` Erreurs réseau (NEL) Échecs DNS, erreurs TLS et connexions interrompues, consignés par le navigateur qui les a subis. Le Network Error Logging demande son propre en-tête NEL et un groupe Report-To, et reste aujourd'hui réservé à Chromium. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/network-error) `crash` Plantages L'onglet a planté ou est tombé à court de mémoire. Une page morte ne peut pas exécuter de script de surveillance ; la Reporting API est le seul témoin. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/crash) `deprecation` Dépréciations Vos pages appellent une API que le navigateur prévoit de retirer, avec la date de retrait quand il la connaît. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/deprecation) `intervention` Interventions Le navigateur a modifié de lui-même le comportement de votre page : une lecture automatique refusée, un script lent bridé. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/intervention) ### Hygiène des politiques La preuve que vos politiques d'isolation et de permissions tiennent réellement en production. `permissions-policy-violation` Violations de Permissions Policy Du code a demandé la caméra, la géolocalisation ou une autre fonctionnalité restreinte contre votre Permissions-Policy. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/permissions-policy-violation) `document-policy-violation` Violations de Document Policy Un comportement de la page a enfreint la configuration déclarée par votre Document-Policy. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/document-policy-violation) `coop` Violations COOP Une interaction de fenêtre cross-origin que votre Cross-Origin-Opener-Policy a bloquée ou bloquerait. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/coop) `coep` Violations COEP Une ressource chargée sans l'opt-in que votre Cross-Origin-Embedder-Policy exige. [Voir la doc](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/coep) Couverture ## Des rapports de chaque visiteur, partout. Votre surveillance opère partout où sont vos utilisateurs : chaque navigateur, chaque réseau, chaque pays d'où vient votre trafic. ### Prise en charge complète du Reporting-API Les 12 types de rapports, sur les deux générations d'en-têtes, vers un seul endpoint. Si un navigateur peut l'envoyer, nous le collectons. ### Signal en temps réel Les rapports arrivent dans votre flux quelques instants après leur envoi par le navigateur, déjà dédupliqués et classés. Les règles d'alerte se déclenchent en direct. ### Conçu pour l'échelle 1,5 milliard de rapports ingérés et ce n'est pas fini, hébergés en France chez OVH et ne quittant jamais l'UE. Un pic de violations le jour le plus chargé est le moment où le flux compte le plus : il ne décroche jamais. Après la collecte ## Collecter n'est que la moitié du travail. Ce que la plateforme fait des rapports une fois parsés. ### Tableau de bord en direct Filtrez le flux par type de rapport, directive, navigateur ou origine, et explorez le JSON brut de chaque rapport. - Flux filtré par type, directive, navigateur, origine - JSON brut pour chaque rapport - Scores et inventaires par site [Ouvrir le tableau de bord](https://app.centralcsp.com) ### Règles d'alerte Nouvelle origine, changement de hash, pic de violations : acheminez ce qui compte vers les canaux que votre équipe utilise déjà. - Règles nouvelle origine et changement de hash - Détection des pics de violations - Slack, Teams, Google Chat, Telegram, e-mail [Voir les alertes](https://centralcsp.com/fr/platform/alerting/) ### API et MCP Tout le flux est interrogeable via l'API REST, exportable en CSV et pilotable par des agents IA via MCP. - API REST avec clés API de workspace - Exports CSV et rapports bruts - Serveur MCP intégré [Voir l'API](https://centralcsp.com/fr/platform/api-mcp/) ### Générateur de CSP Transformez les violations collectées en une Content Security Policy adaptée à votre trafic réel, puis resserrez-la au fil du temps. - Politique construite à partir des rapports de production - Suggestions directive par directive - Testez d'abord en report-only [Voir le générateur de CSP](https://centralcsp.com/fr/platform/csp-builder/) ### Preuves PCI DSS Les mêmes rapports alimentent un inventaire continu des scripts de vos pages de paiement, exporté en preuves prêtes pour l'audit. - Exigences 6.4.3 et 11.6.1 - Inventaire continu des scripts - Exports prêts pour l'audit [Voir PCI DSS](https://centralcsp.com/fr/platform/pci-dss/) ### Chaîne d'approvisionnement Chaque script de votre inventaire est vérifié contre les CVE connues, une dépendance compromise ne reste donc pas silencieuse. - CVE connues signalées dans vos scripts - Détection des nouveaux scripts - Alimenté par les mêmes rapports [Voir la chaîne d'approvisionnement](https://centralcsp.com/fr/platform/supply-chain/) Pour aller plus loin ## La référence, avant de brancher Comment fonctionne la Reporting API, quel en-tête envoyer, et ce que devient un rapport une fois arrivé. - [Comment fonctionne la Reporting API](https://centralcsp.com/fr/docs/web-security/reporting-api/concepts/how-the-reporting-api-works) - [L'en-tête Reporting-Endpoints](https://centralcsp.com/fr/docs/web-security/reporting-api/headers/reporting-endpoints) - [Connecter votre site, étape par étape](https://centralcsp.com/fr/docs/platform/websites/connect-your-site) - [Lire le guide de la surveillance](https://centralcsp.com/fr/docs/platform/monitoring) - [Durée de conservation des rapports](https://centralcsp.com/fr/docs/platform/security/data-retention) - [Où vont les rapports CSP, et faut-il coder son collecteur](https://centralcsp.com/fr/blog/where-to-send-csp-reports) FAQ ## Questions fréquentes Performance, confidentialité et prise en charge navigateur : les réponses. ### La collecte de rapports ralentit-elle mon site ? Non. Il n'y a aucun script à charger : le navigateur génère les rapports lui-même et les envoie par lots, en arrière-plan, jusqu'à une minute après le chargement de la page. Vos pages livrent les mêmes octets qu'avant, plus un en-tête de réponse. ### Combien de temps les rapports sont-ils conservés ? Les rapports navigateur sont conservés 90 jours. Cette fenêtre est fixe et non configurable. Les décisions que vous prenez à partir d'eux, comme les justifications de scripts et les entrées du journal d'audit, sont conservées jusqu'à la suppression du compte, parce que ce sont ces enregistrements qu'une évaluation réclame, pas la télémétrie brute. ### Les rapports navigateur contiennent-ils des données personnelles ? La charge utile contient des URL, des directives, des emplacements source et la famille du navigateur ; elle ne contient ni cookies, ni saisies de formulaire, ni identité de session. Les URL peuvent toutefois porter des données personnelles dans leurs paramètres de requête (un e-mail ou un jeton dans une query string, par exemple) : CentralCSP propose donc une option pour supprimer les paramètres de requête des rapports collectés avant tout stockage. Les rapports sont stockés en France, chez OVH, et ne quittent jamais l'UE. ### Quels navigateurs envoient des rapports ? Pratiquement tous. Les navigateurs récents rapportent via la Reporting API ; les plus anciens envoient encore les violations CSP via la directive historique report-uri. CentralCSP accepte les deux formats sur le même endpoint, donc chaque navigateur de votre trafic rapporte. ### Quelle est la différence entre report-uri, report-to et Reporting-Endpoints ? Ce sont trois générations de la même idée : report-uri est la directive CSP historique, Report-To est arrivé avec la première Reporting API, et Reporting-Endpoints est l'en-tête actuel. Déployez Reporting-Endpoints plus report-uri et chaque génération est couverte ; les deux livrent au même endpoint CentralCSP. ### Pourquoi les rapports CSP incluent-ils des violations qui n'en sont pas ? Les extensions de navigateur comme les bloqueurs de publicité et les gestionnaires de mots de passe injectent du code dans chaque page, et ce code déclenche votre politique. C'est la principale source de bruit CSP. CentralCSP collecte aussi ces rapports, et les signale comme bruit d'extension pour que vous distinguiez d'un coup d'œil ce qui compte sur votre site. ### Faut-il une Content Security Policy avant de pouvoir surveiller ? Non. Les rapports crash, deprecation et intervention ne demandent que l'en-tête Reporting-Endpoints. Les erreurs réseau font exception : elles demandent leur propre en-tête NEL et un groupe Report-To. Pour la CSP, vous pouvez commencer avec Content-Security-Policy-Report-Only, qui rapporte tout et ne bloque rien. ### Puis-je simplement coder mon propre collecteur de rapports ? Oui. Un endpoint est une URL qui accepte des POST en application/reports+json, et en application/csp-report pour l'ancien format report-uri, et renvoie un code 2xx. L'endpoint est la partie facile. Ce qui suit, c'est le volume, parce qu'un site actif génère bien plus de rapports que de pages vues le jour où une politique est mauvaise ; la déduplication, parce que la même violation arrive des milliers de fois ; le bruit des extensions de navigateur, qui représente la majorité de ce que reçoit un endpoint ouvert ; et un stockage qui doit rester interrogeable. CentralCSP, c'est ces quatre points, pas l'URL. ### Que se passe-t-il lors d'un pic de violations, ou quand un site atteint son quota ? Chaque site dispose de son propre plafond : un site mal configuré ne peut donc pas épuiser à lui seul le quota du workspace. Les filtres d'ingestion permettent de restreindre les origines autorisées à envoyer des rapports, ce qui évite qu'un endpoint ouvert absorbe du trafic qui n'est pas le vôtre. Vous recevez des avertissements d'usage à 80 % et 100 % du quota par e-mail, et l'ingestion s'arrête à la limite plutôt que de facturer au-delà. ## Votre prochain visiteur peut être votre premier rapport. Ajoutez l'en-tête et regardez le flux se remplir de trafic réel. Essai gratuit de 14 jours, aucun agent à déployer. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Vérifiez votre configuration de reporting](https://centralcsp.com/fr/tools/reporting-api/) --- Disponible en : [en](https://centralcsp.com/en/platform/monitoring/), [fr](https://centralcsp.com/fr/platform/monitoring/)