--- title: "Surveillance des scripts tiers et protection Magecart" description: "Magecart et supply chain côté client : inventoriez chaque script exécuté par vos visiteurs, sa version et ses CVE, alerte au moindre changement. Sans agent." url: "https://centralcsp.com/fr/platform/supply-chain/" lang: "fr" --- Sécurité supply chain # Chaque script que vos visiteurs exécutent, et ce qu'il contient. Votre pare-feu ne voit jamais les scripts tiers dans les navigateurs de vos visiteurs. Nous, si : chaque script, sa bibliothèque et sa version, et l'instant où il change ou récolte une CVE. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Réserver une démo](https://centralcsp.com/fr/contact/?topic=demo) - 0 script ajouté Rapport natif des navigateurs - Trafic de vrais visiteurs Pas un instantané de crawler - Détection des CVE Fingerprinting du contenu - Résidence des données dans l'UE France, chez OVH La menace ## La brèche qui ne touche jamais votre serveur. Une attaque supply chain côté client compromet un script tiers que votre page charge déjà : le code malveillant s'exécute donc dans le navigateur de vos visiteurs, pas sur vos serveurs. L'outillage côté serveur ne la voit pas, parce que rien n'a changé sur votre infrastructure. Notre recensement annuel a mesuré que 22,0 % du web expédie une Content-Security-Policy, et que seuls 0,97 % des domaines en ont une qui passe. Trois incidents, trois portes d'entrée. 1. ### Polyfill.io, 2024 Le domaine polyfill.io a changé de mains en février. En juin, le CDN derrière lui injectait des redirections malveillantes dans les pages de plus de 100 000 sites qui intégraient une seule balise script. Le code esquivait les comptes admin et les outils d'analytics : les sites qui ne testaient que leurs propres pages ne voyaient rien. [Le rapport de Sansec](https://sansec.io/research/polyfill-supply-chain-attack) 2. ### British Airways, 2018 Des attaquants Magecart ont modifié environ 22 lignes d'un fichier Modernizr sur ba.com. Pendant 15 jours, chaque formulaire de paiement a envoyé les cartes vers un domaine attaquant. Environ 400 000 clients touchés ; l'amende de l'ICO s'est conclue à 20 millions de livres. [L'avis de sanction de l'ICO](https://ico.org.uk/media2/migrated/2618421/ba-penalty-20201016.pdf) 3. ### npm chalk et debug, 2025 18 paquets totalisant 2,6 milliards de téléchargements hebdomadaires ont livré des versions malveillantes après le phishing d'un mainteneur. La charge s'exécutait dans les navigateurs des utilisateurs finaux, détournant fetch et les API de wallets. Tous les contrôles de build sont passés à l'installation ; l'attaque a tourné après le build. [L'analyse d'Aikido](https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised) Comment ça marche ## Un en-tête de réponse en entrée. Chaque script comptabilisé. Aucun agent à charger, aucun proxy dans votre chaîne de livraison, aucun robot qui visite votre site. Les navigateurs de vos vrais visiteurs sont les capteurs. 1. 01 - Collecter ### Les navigateurs rapportent chaque script exécuté Ajoutez un en-tête de réponse. Dès lors, les navigateurs de vos vrais visiteurs rapportent l'URL et le hash de chaque script exécuté par vos pages : les vôtres, ceux des tiers, et les scripts de quatrième partie que vos tiers chargent après leur exécution, comme le tag que votre tag manager a récupéré cette nuit. 2. 02 - Analyser ### Nous identifions ce que chaque script contient Le contenu de chaque script est fingerprinté et analysé pour identifier la bibliothèque, le framework ou le fournisseur derrière lui, et sa version. Cette identité est confrontée aux bases de CVE connues et au statut de cycle de vie : obsolète, non maintenu, en fin de vie. 3. 03 - Agir ### Changements et CVE deviennent des alertes Un nouveau script, un hash modifié, une nouvelle origine sortante ou une CVE fraîche notifie Slack, Teams, Google Chat, Telegram ou l'e-mail dès que les navigateurs le rapportent. Corrigez le constat, ou bloquez le vecteur avec une CSP construite depuis les mêmes rapports. ### Un inventaire des scripts tiers construit par votre trafic réel. Les skimmers se camouflent : ils se déclenchent sur de vrais checkouts dans de vraies sessions et restent dormants face aux crawlers et aux sandboxes. L'inventaire de CentralCSP vient de ce que les navigateurs de vos vrais visiteurs ont exécuté, donc un script qui ne dérape qu'en production figure quand même sur la liste. - Scripts first-party et tiers, par page - Scripts de quatrième partie : ceux que vos tiers chargent après leur exécution - Dernières apparitions issues du trafic en direct - Nouveaux scripts signalés dès leur apparition ### Une CVE dans un tag marketing reste votre CVE. Le nom de fichier d'un script ne dit rien du jQuery qu'il contient. CentralCSP fingerprinte le contenu de chaque script, résout la bibliothèque et la version qu'il embarque, et le confronte aux bases de CVE et au statut de maintenance. Vous corrigez la version vulnérable avant que quelqu'un d'autre ne la trouve. - Fingerprinting du contenu, pas seulement de l'URL - CVE connues rattachées à la version exacte - Versions en fin de vie et non maintenues signalées ### Le SBOM que votre pipeline de build ne peut pas produire. Votre CI scanne ce qui est dans le dépôt. La charge du tag manager, le widget de chat et le snippet d'analytics n'y passent jamais, et la compromission npm de septembre 2025 a franchi tous les contrôles de build avant de faire ses dégâts dans les navigateurs. Ce SBOM liste ce qui a réellement tourné côté client. - Technologies et versions depuis les pages en production - Couvre les scripts qui ne passent jamais par votre dépôt - Exportez-le pour vos revues de sécurité et audits ### Une donnée qui quitte la page est un rapport, pas un mystère. Le web skimming a deux signes : un fichier qui a changé, et des données qui partent vers une origine que vous n'avez jamais approuvée. Les navigateurs rapportent les deux, nommément. Un script qui ne correspond plus à son hash SRI arrive en rapport integrity-violation ; un script dont les octets ont changé arrive en rapport de hash csp-hash ; une page qui dialogue avec une origine non déclarée arrive en rapport de connexion. - Connexions sortantes vers des origines inconnues rapportées - Les écarts SRI arrivent en rapports integrity-violation - Les changements d'octets arrivent en rapports de hash de script csp-hash Prévention ## La détection vous prévient. La configuration bloque. Les rapports qui construisent votre inventaire durcissent aussi votre politique : verrouillez ce qui peut se charger et où les données peuvent aller, puis laissez le navigateur appliquer. ### Une CSP issue du trafic réel Le CSP builder transforme les rapports collectés en une politique taillée pour votre site : sources de scripts limitées à ce que vous utilisez vraiment, connect-src et form-action fermés aux origines inconnues, pour qu'un skimmer n'ait nulle part où envoyer les données. - Construite depuis les rapports de production - Destinations d'exfiltration verrouillées - Report-only d'abord, appliquée une fois stable [Voir le générateur de CSP](https://centralcsp.com/fr/platform/csp-builder/) ### Intégrité sur vos assets Épinglez vos scripts statiques avec Subresource Integrity et un fichier substitué refuse de s'exécuter. Les navigateurs rapportent chaque incohérence, donc l'altération se voit même là où vous ne pouvez pas épingler. - Hash SRI générés en quelques secondes - Violations d'intégrité rapportées en direct - Couvre le mode de défaillance de polyfill.io [Générer des hash SRI](https://centralcsp.com/fr/tools/sri-hash/) ### En-têtes notés en continu Les scanners gratuits notent votre CSP et vos en-têtes de sécurité comme un attaquant les lit : quelles origines peuvent exécuter du code, quelles destinations peuvent recevoir des données, quel reporting vous auriez pendant un incident. - Scan de la CSP et des en-têtes - Configuration de reporting vérifiée - Gratuit, sans compte [Scanner vos en-têtes](https://centralcsp.com/fr/tools/security-headers/) Approches ## Trois façons de surveiller vos scripts. Trois modèles de déploiement, avec les noms qu'emploient les acheteurs : reporting sans agent, agent injecté, et livraison par proxy. Chaque produit de sécurité côté client répond différemment à une seule question : que devez-vous ajouter à votre site pour obtenir de la visibilité ? Voici la comparaison honnête que les éditeurs évitent. Comparaison des modèles de déploiement de sécurité côté client | | CentralCSP (sans agent) | Agent injecté | Livraison par proxy | | --- | --- | --- | --- | | N'ajoute rien à votre page | Rien, un en-tête | Son propre script | Un proxy sur le chemin | | Voit de vraies sessions visiteur | Chaque navigateur rapporte | Tant que son script tourne | Trafic proxifié seulement | | Attrape les skimmers furtifs | Se déclenche sur de vrais checkouts | Sauf s'il est esquivé | Si la charge est inspectée | | Produit les preuves PCI DSS 6.4.3 | Inventaire et justifications exportables | Variable selon le produit | Variable selon le produit | | Bloque les scripts malveillants dans la page | Via votre CSP | Blocage dans le navigateur | Bloque à l'edge | | N'ajoute ni poids de page ni latence | Zéro octet ajouté | S'exécute sur chaque page | Latence à chaque fetch | | N'ajoute aucune surface d'attaque | Jamais dans la page | Un tiers de plus | Il sert votre code | Vérifiez votre exposition ## À quel point votre site est-il exposé, là, maintenant ? Deux minutes : voyez quelles origines peuvent exécuter du code sur vos pages aujourd'hui, et si vous en entendriez seulement parler quand l'une tourne mal. Scanner mon site Gratuit, sans compte. Les résultats arrivent sur une page partageable. Adopté par des équipes du monde entier Tarifs ## La détection de CVE démarre avec l'offre Scale. L'inventaire des scripts est inclus dès l'offre Start, et les alertes, le scan automatisé et l'API et le MCP complets arrivent avec Business. Scale ajoute la détection de CVE, aux côtés des preuves pages de paiement pour PCI DSS. - Inventaire des scripts depuis le trafic réel - Détection des CVE et fins de vie - Alertes nouveau script et changement de hash - API, MCP et exports CSV ### Scale Les preuves PCI DSS v4, à l'échelle d'un portefeuille. 349,99 € / mois - Applications 30 - Utilisateurs 100 - Rapports / mois 10 000 000 Tout ce qui est dans Business, plus : - Détection des CVE - Surveillance des pages de paiement - Preuves PCI DSS - SSO et journal d'audit - Facturation et accompagnement achats [Commencer](https://app.centralcsp.com/?plan=scale&billing=monthly) ## Vous encaissez des paiements ? C'est désormais obligatoire. Depuis mars 2025, PCI DSS v4 exige un inventaire justifié de chaque script de page de paiement (6.4.3) et des alertes sur les changements non autorisés (11.6.1). C'est exactement le périmètre de cette page, pointé sur votre checkout, avec les exports de preuves que votre évaluateur demande. [Voir les preuves PCI DSS](https://centralcsp.com/fr/platform/pci-dss/) - Inventaire des scripts avec justifications - Alertes de changement et d'altération - Exports de preuves CSV et PDF - SBOM pour l'évaluateur Pour aller plus loin ## Comment fonctionnent vraiment les attaques côté client D'où viennent les skimmers, comment se construit un inventaire des scripts, et comment imposer l'intégrité sur chaque ressource. - [Les rapports de hash de script](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/csp-hash) - [Détecter un skimmer côté client](https://centralcsp.com/fr/blog/magecart-formjacking-detection) - [Construire un inventaire des scripts avec les hash CSP](https://centralcsp.com/fr/blog/script-inventory) - [Imposer SRI à tous les scripts avec Integrity-Policy](https://centralcsp.com/fr/blog/integrity-policy-explained) - [Comment les attaquants détournent Google Tag Manager](https://centralcsp.com/fr/blog/google-tag-manager-security-risk) - [CSP et PCI DSS v4 : 6.4.3 et 11.6.1](https://centralcsp.com/fr/blog/csp-pci-dss-v4) FAQ ## Questions fréquentes Les attaques supply chain côté client et comment nous les attrapons, en clair. ### Qu'est-ce que Magecart, et est-ce la même chose que le formjacking ou l'e-skimming ? Magecart est le nom donné à la famille d'attaques qui injectent du JavaScript de skimming dans les pages de paiement et de connexion pour voler numéros de carte et identifiants au moment de la saisie. Formjacking, e-skimming et web skimming décrivent la même technique sous d'autres noms. Le trait déterminant est le lieu d'exécution : le vol se produit dans le navigateur du visiteur, dans la page que vous avez servie, et c'est pourquoi vos journaux serveur et votre base de données paraissent intacts ensuite. La brèche British Airways présentée sur cette page en est le cas d'école. ### Qu'est-ce qu'une attaque supply chain côté client ? Une attaque qui atteint vos utilisateurs via du code que vos pages chargent chez un tiers : un script tiers, un CDN, un tag manager, un paquet npm qui finit dans votre bundle. Le fournisseur est compromis, votre page livre la charge malveillante, et le vol se produit dans le navigateur du visiteur. Vos serveurs ne sont jamais touchés, c'est pourquoi l'outillage côté serveur passe à côté. ### Une Content Security Policy peut-elle arrêter les attaques Magecart ? Elle arrête beaucoup de choses : une CSP stricte bloque les scripts des origines que vous n'avez jamais approuvées et, via connect-src et form-action, empêche l'envoi de données vers le serveur de l'attaquant. Ce qu'elle ne peut pas juger, c'est un fournisseur approuvé qui devient malveillant, exactement ce qui est arrivé à British Airways. C'est pourquoi CentralCSP associe la politique à un inventaire des scripts, au fingerprinting de leur contenu et à des alertes de changement : la CSP ferme les portes, la surveillance des scripts observe les fournisseurs que vous laissez entrer. ### Subresource Integrity suffit-elle à elle seule ? C'est un vrai contrôle, et il ne suffit pas. SRI épingle un fichier dont vous maîtrisez le balisage : vous placez le hash dans la balise, et le navigateur refuse le fichier si les octets diffèrent. Cela couvre une bibliothèque remplacée sur un CDN. Cela ne couvre pas un script injecté à l'exécution par un tag manager, ni un script chargé par un autre script, parce qu'aucun des deux n'a de balise dans laquelle vous auriez écrit un hash. C'est précisément pour cet écart que le navigateur rapporte aussi les violations d'intégrité et les changements de hash : SRI vous signale qu'un fichier épinglé a été remplacé, et les rapports de hash vous renseignent sur tout ce qui n'a jamais été épinglé. ### Pourquoi mon WAF ou mon scanner de dépendances ne détectent-ils pas ces attaques ? Ils sont au mauvais endroit. Le WAF inspecte le trafic vers vos serveurs, or un skimmer envoie les données du navigateur du visiteur directement vers le domaine de l'attaquant : le WAF ne voit jamais la requête. Votre scanner de dépendances vérifie le code de votre dépôt, et la charge du tag manager ou le widget de chat n'y passent jamais. Le seul endroit où chaque script est visible, c'est le navigateur qui l'exécute, et c'est de là que viennent les rapports de CentralCSP. ### Comment CentralCSP détecte-t-il les CVE dans mes scripts ? Les navigateurs rapportent l'URL et le hash de chaque script que vos pages exécutent. CentralCSP fingerprinte le contenu de chaque script et exécute sa propre analyse pour identifier la bibliothèque ou le framework qu'il contient et sa version exacte, puis confronte cette identité aux bases de CVE connues et aux données de cycle de vie. Vous obtenez le constat rattaché au script et à la page concernés : une CVE connue, une version en fin de vie, ou une bibliothèque qui n'est plus maintenue. ### En combien de temps saurai-je qu'un script a changé ? À mesure que les rapports arrivent du trafic réel. Les navigateurs mettent les rapports en file et les envoient en arrière-plan, généralement dans la minute qui suit le chargement de la page, si bien qu'un nouveau script, un hash modifié ou une nouvelle origine sortante apparaît dès que de vrais visiteurs ont chargé la page. La règle d'alerte se déclenche sur cet événement, pas sur un planning. Le contraste utile est celui des contrôles par crawler, qui vous informent à la cadence que vous leur fixez : PCI DSS 11.6.1 place le plancher à une fois tous les sept jours, et un crawl hebdomadaire respecte ce plancher tout en laissant six jours pendant lesquels un skimmer est actif et non signalé. ### Qu'est-ce qu'un SBOM côté client ? Un inventaire logiciel de ce qui s'exécute dans le navigateur plutôt que de ce qui se trouve dans votre dépôt. Un SBOM de build s'arrête à votre bundle ; le SBOM côté client couvre aussi les scripts que vos pages chargent à l'exécution, du tag manager au widget de support, avec la version et le statut de vulnérabilité de chacun. C'est la liste qu'une revue de sécurité veut vraiment : le code qui a tourné devant l'utilisateur. ### CentralCSP ajoute-t-il un script ou de la latence à mon site ? Non. La détection repose sur la Reporting API : les navigateurs génèrent les rapports nativement et les envoient en arrière-plan, vos pages livrent donc les mêmes octets qu'avant, plus un en-tête de réponse. Il n'y a aucun agent à compromettre, aucun proxy dans votre chaîne de livraison, et rien de nouveau à ajouter à votre propre inventaire de scripts. ## Découvrez ce que vos pages ont exécuté aujourd'hui. Ajoutez l'en-tête cet après-midi et l'inventaire se construit tout seul avec vos prochains visiteurs. Essai gratuit, sans agent, sans proxy, sans changement de code. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Scanner votre site gratuitement](https://centralcsp.com/fr/tools/security-headers/) --- Disponible en : [en](https://centralcsp.com/en/platform/supply-chain/), [fr](https://centralcsp.com/fr/platform/supply-chain/)