Comment les équipes sécurité bancaires surveillent leur CSP sans envoyer de données hors de l’UE

Le modèle de menace d’une banque côté navigateur a une particularité : le code de l’attaquant n’a pas besoin de toucher l’infrastructure de la banque. Un script d’analytics empoisonné, un widget de chat compromis, ou une faille XSS sur une page marketing voisine du formulaire de connexion suffisent à skimmer identifiants ou données de paiement depuis une session parfaitement légitime. La Content Security Policy est l’un des rares contrôles qui porte jusque dans cet environnement. C’est pour cela que les équipes sécurité des institutions financières la déploient, la surveillent et traitent la télémétrie produite avec le même soin que n’importe quel autre flux de données clients.

C’est sur ce dernier point que le choix du fournisseur devient précis.

Les rapports de violation sont de la télémétrie client

Chaque rapport de violation CSP est généré par le navigateur d’un client. Il contient l’URL du document consulté, le référent, l’URL de la ressource bloquée et du contexte navigateur. Dans une application bancaire, URL et référents peuvent transporter des artefacts de session, des chemins d’espace client ou des identifiants de campagne. Dès que vous pointez report-to vers un endpoint tiers, vous créez un transfert récurrent de télémétrie navigateur vers ce fournisseur.

Pour une institution financière européenne, les questions s’enchaînent mécaniquement : où l’endpoint est-il hébergé, qui traite les données, sous quel contrat, pour combien de temps ? Un fournisseur de surveillance CSP est un sous-traitant comme un autre. Beaucoup d’équipes l’intègrent pourtant à la légère, parce que « ce ne sont que des rapports de violation ».

Ce qu’il faut exiger d’un fournisseur

Une checklist de due diligence raisonnable pour la surveillance CSP en environnement financier régulé :

• Résidence UE des données pour le traitement, pas seulement le stockage, avec des sous-traitants nommés.
• Un DPA signé, assorti de clauses contractuelles types dès qu’une partie hors EEE intervient.
• Une rétention bornée avec suppression automatique. La télémétrie de violations n’a pas besoin de vivre des années.
• Des contrôles d’accès de niveau entreprise : SSO en SAML ou OIDC, gestion par rôles jusqu’au site individuel et un journal d’audit complet de qui a vu et modifié quoi.
• Des preuves exportables, pour l’audit interne, pour les régulateurs (DORA fait des prestataires TIC un sujet de conseil d’administration) et pour les évaluateurs PCI DSS quand des données de carte sont en jeu.
• Aucun agent requis. Une surveillance qui passe par un en-tête de réponse garde le fournisseur lui-même hors de la supply chain de vos pages, au lieu d’ajouter un énième script tiers dans la session authentifiée.

Ce dernier point mérite qu’on s’y arrête. Plusieurs produits de sécurité client-side protègent les pages de paiement en y injectant leur propre agent JavaScript, ce qui peut être le bon compromis pour de la détection comportementale. Le fournisseur de surveillance devient alors l’un des scripts que votre CSP doit autoriser et une ligne de plus dans votre registre des risques tiers.

Où se situe CentralCSP

CentralCSP a été construit dans cette posture dès l’origine. C’est une société française (CentralSaaS, près de Grenoble), qui indique que toutes les données clients et utilisateurs finaux sont stockées et traitées sur des serveurs OVH en France et ne quittent jamais l’Union européenne, avec un DPA public et une rétention glissante fixe de 90 jours sur les rapports navigateur. Des alternatives hébergées au Royaume-Uni ou aux États-Unis peuvent être des sous-traitants parfaitement légitimes sous clauses contractuelles types. Un fournisseur de droit européen sur infrastructure européenne reste néanmoins une ligne plus simple dans une analyse d’impact de transfert.

Sur les questions d’assurance que posera votre équipe risques tiers, voici les réponses en septembre 2026, et nous préférons les écrire ici plutôt que vous les laisser découvrir dans un questionnaire : une page de statut publique, un plan de reprise d’activité, un premier pentest indépendant programmé pour la fin 2026 sans rapport disponible à ce jour, et aucune certification SOC 2 ni ISO 27001. Les contrats Enterprise comportent un engagement contractuel de disponibilité, dont le chiffre se négocie contrat par contrat plutôt que de figurer sur une page tarifaire.

Opérationnellement, la surveillance passe par le seul en-tête CSP : aucun agent dans la session bancaire. La plateforme maintient un inventaire de scripts issu du navigateur avec hashes d’intégrité sur tous les plans, et l’identification de la version de bibliothèque et des CVE connues (la vue Technologies) à partir de Scale. Les alertes, dès Business, s’évaluent à l’ingestion et non sur un planning, sans plafond mensuel, sur 16 types d’événements dont la nouvelle origine de script, et arrivent sur Slack, Microsoft Teams, Google Chat, Telegram, par email ou par webhook signé HMAC vers Splunk, Datadog ou ce que fait tourner votre SOC, avec un historique de livraison par canal. L’API REST et le serveur MCP, dès Business également, permettent de tirer rapports bruts, inventaire et journal d’audit vers un SIEM ou un entrepôt de données à votre rythme. Le module PCI DSS du plan Scale tient des chronologies de changement datées et des exports de preuves CSV ou PDF pour la 6.4.3 et la 11.6.1 quand des pages de paiement sont concernées, et ces données de conformité sont conservées jusqu’à la suppression du compte, bien au-delà de la fenêtre de 90 jours des rapports. Le contrôle d’accès par rôles, avec rôles d’espace de travail, rôles par site et groupes, est inclus dans tous les plans. Le SSO (SAML ou OIDC) et le journal d’audit exportable démarrent à Scale, pas à Enterprise. Pour une première lecture de l’état d’une page de paiement, le scanner CSP gratuit note une URL en ligne en sécurité et en qualité sans ouvrir de compte.

Un schéma de déploiement qui fonctionne en banque

1. Commencez par Content-Security-Policy-Report-Only sur les pages publiques, puis étendez aux espaces authentifiés. Le mode report-only ne peut pas casser un parcours client.
2. Laissez deux à quatre semaines de trafic réel construire l’inventaire de scripts, puis relisez-le avec les équipes fraude et risques tiers, pas seulement l’ingénierie.
3. Passez en mode strict d’abord sur les parcours de connexion et de paiement : valeur maximale, surface de scripts minimale.
4. Branchez les alertes sur le SOC par webhook signé. Les règles sont définies par site : donnez aux propriétés de connexion et de paiement leur propre site et leurs propres règles. Une nouvelle origine de script sur une page de connexion est un incident majeur, pas une ligne de dashboard.
5. Exportez la chronologie de changements chaque trimestre dans votre dossier de preuves d’audit, pour que la conformité cesse de demander des captures d’écran à l’ingénierie.

Le navigateur est la seule partie du périmètre d’une banque qui tourne sur du matériel qu’elle ne possédera jamais. La surveillance CSP est votre télémétrie depuis cet environnement. Choisissez où elle atterrit avec le même soin que vous avez mis à choisir l’hébergement de votre core banking.