# Comment être alerté quand votre page de paiement charge un nouveau script

> Un skimmer Magecart, c'est un script nouveau ou modifié sur vos pages de paiement. Le détecter en quelques minutes via l'en-tête CSP, avec des alertes sur les nouvelles origines de script et les scripts de paiement non justifiés, livrées dans Slack, Teams ou votre SIEM. Sans agent sur la page.

- Canonical: https://info.centralcsp.com/fr/articles/checkout-page-new-script-alerts/
- Published: 2026-08-09
- Language: fr
- Publisher: CentralCSP (https://centralcsp.com)

Pour être alerté quand votre page de paiement charge un nouveau script, faites rapporter par le navigateur de chaque visiteur les scripts qu'il exécute (l'en-tête `Content-Security-Policy` le fait nativement, via le hash reporting), alimentez un inventaire de scripts avec ces rapports et posez dessus deux règles d'alerte : une pour toute origine de script que vos visiteurs n'ont jamais chargée, une pour tout script qui apparaît sans justification sur les pages que vous avez déclarées comme pages de paiement. Dès que l'un des deux se produit, la règle part à l'ingestion vers Slack, Teams, l'e-mail ou un webhook. Détection en quelques minutes, sans crawler, sans agent sur la page.

Voilà l'architecture complète. Le reste explique pourquoi chaque brique compte et comment régler l'ensemble.

## Pourquoi la revue mensuelle trouve le skimmer avec un mois de retard

Le mode opératoire Magecart n'a presque pas bougé en dix ans : compromettre un script qui tourne déjà sur le checkout (un widget de chat, un tag analytics, un bundle servi par un CDN compromis), ou en injecter un nouveau, précisément sur les pages où les numéros de carte sont saisis. Le skimmer ressemble à n'importe quel script tiers. Il ne casse rien.

C'est pour cela que le rituel mensuel de « revue des scripts du checkout » échoue. Le skimmer de British Airways a tourné environ deux semaines, et beaucoup d'incidents plus discrets tournent des mois. Si votre cadence de détection est une entrée d'agenda, votre délai de détection vaut la moitié de l'intervalle dans le meilleur des cas. En pratique c'est pire, parce que le relecteur compare à un tableur déjà périmé.

Un scanner à base de crawler fait mieux, mais rate les skimmers servis uniquement aux vrais utilisateurs (détecter un navigateur headless est un standard chez les attaquants) et tout ce qui se passe entre deux passages.

## À quoi ressemble une bonne détection sur une page de paiement

Trois propriétés, par ordre d'importance.

**Côté navigateur.** Le besoin est de savoir ce que les navigateurs de vrais clients ont exécuté, parce que c'est là que circulent les données de carte. Un skimmer injecté par un CDN compromis ne touche jamais vos serveurs : la supervision d'intégrité côté serveur ne le verra pas.

**Limitée aux parcours de paiement.** Un nouveau script sur le blog, c'est un mardi ordinaire. Un nouveau script sur `/checkout/payment`, c'est un incident jusqu'à preuve du contraire. Une détection qui traite les deux pareil apprend à votre équipe à l'ignorer.

**Quelques minutes jusqu'au canal d'astreinte.** Pas un tableau de bord qu'on consulte, pas un résumé hebdomadaire. Entre « nouveau hash observé » et « un humain regarde », exactement une notification Slack.

Une quatrième propriété, souvent sous-estimée : le mécanisme de détection ne doit pas lui-même ajouter de script au checkout. Plusieurs produits client-side posent leur agent JavaScript sur la page de paiement, soit un tiers de plus sur la page exacte que vous protégez, invité au passage dans votre périmètre PCI. Je préfère surveiller la page sans y toucher.

## La mise en place avec CentralCSP

Le [Script Inventory de CentralCSP](https://centralcsp.com/fr/platform/supply-chain/) est construit sur le hash reporting de CSP (`report-sha256` et ses variantes) : chaque script chargé sur vos pages arrive dans l'inventaire, page par page, avec son origine, son URL complète, son hash SHA-256 et l'historique de ses hash, première et dernière observation. Un en-tête HTTP à déployer, rien de nouveau qui s'exécute sur le checkout, et l'inventaire est présent sur toutes les offres. Le mécanisme est détaillé dans [notre article sur la détection des changements de scripts tiers](/fr/articles/detect-third-party-script-changes/).

Au-dessus de l'inventaire, les [règles d'alerte](https://centralcsp.com/fr/platform/alerting/) travaillent à deux niveaux.

Le premier couvre tout le site et arrive avec Business (129,99 €/mois) : la règle **nouvelle origine de script**, qui part à l'instant où un hôte qui n'a jamais servi de script à vos visiteurs s'y met. C'est le signal de skimmer le plus bruyant, et celui que la plupart des voies d'injection déclenchent, parce que les attaquants hébergent rarement leur charge sur un domaine auquel vous faites déjà confiance. Elle ignore aussi vos propres déploiements par construction : `app.3f2a91.js` qui devient `app.8bc410.js` sur la même origine n'est pas une nouvelle origine.

Le second travaille à la page et arrive avec Scale (349,99 €/mois), là où vit le module PCI DSS. Vous déclarez vos pages de paiement (`/checkout/*`, les pages qui hébergent votre iframe de paiement), le module inventorie leurs scripts depuis le trafic réel, et chaque script est autorisé avec une justification écrite. Tout ce qui apparaît ensuite sur ces pages, une URL inédite ou une URL connue qui sert un hash qu'aucune règle d'auto-validation ne couvre, tombe dans une file d'attente, s'inscrit dans une chronologie datée des changements et déclenche la règle **script non justifié sur une page de paiement**. C'est le cas de l'altération, celui qu'une liste blanche d'URL ne voit pas, et celui pour lequel la 11.6.1 a été écrite.

La livraison se fait vers Slack, Microsoft Teams, Google Chat, Telegram, l'e-mail ou des webhooks HTTPS signés en HMAC dont le JSON s'intègre à Splunk, Datadog, PagerDuty, Opsgenie ou Jira sans adaptateur (compatibles webhook, pas des connecteurs natifs). Une règle peut viser jusqu'à 20 canaux, les alertes sont illimitées, les règles s'évaluent à l'ingestion et non sur un planning, et chaque tentative de livraison reste dans un historique avec nouvelles tentatives. Start (39,99 €/mois) a l'inventaire et pas d'alerting, ce qui suffit pour construire une politique mais pas pour garder un checkout.

## Le réglage : chaque alerte doit valoir un réveil

Cadrez serré. La tentation est de surveiller tout le site « tant qu'on y est », et le résultat est un canal que plus personne ne lit au bout de trois semaines. La règle des pages de paiement est celle qui réveille, par le webhook vers PagerDuty ou dans le canal Slack d'astreinte. La règle d'origine, à l'échelle du site, peut partir vers un canal plus calme ou par e-mail et se lire le matin.

Ensuite, éliminez les faux positifs de vos mises en production et de celles de vos fournisseurs. Les noms de fichiers hashés de votre bundler ne déclenchent jamais la règle d'origine. Sur les pages de paiement, une règle d'auto-validation pour la rotation de routine d'un éditeur (le widget de chat qui livre chaque semaine sur son URL habituelle) le garde hors de la file d'attente, alors qu'un hash qui change en dehors de tout motif que vous avez posé y tombe et réveille quelqu'un. Par-dessus, chaque règle a un délai de refroidissement (15 minutes par défaut) et ce qui se déclenche encore pendant ce délai est regroupé en un seul message, pas jeté. Une fois ces filtres posés, ce qui reste est soit une équipe marketing qui a ajouté un tag sans prévenir (une conversation à avoir), soit un vrai incident (une astreinte justifiée).

## L'angle PCI DSS

L'exigence 11.6.1 de PCI DSS v4 impose un mécanisme de détection d'altération sur les pages de paiement, évaluant la page et ses en-têtes tels que reçus par le navigateur du consommateur, au moins tous les sept jours. Une détection continue côté navigateur dépasse ce minimum de très loin, et le fil des alertes sert de preuve. L'outillage de preuve PCI complet (workflow de justification, inventaire par page, chronologie datée des changements, export CSV et PDF pour l'assesseur) est le même module Scale que la règle des pages de paiement, et ses registres sont conservés jusqu'à la suppression du compte, pas seulement les 90 jours des rapports bruts. Le détail est dans [notre analyse de 6.4.3 et 11.6.1](/fr/articles/pci-dss-6-4-3-and-11-6-1-payment-page-requirements/).

S'il ne fallait retenir qu'une chose : l'attaque, c'est un script nouveau ou modifié sur un ensemble de pages connu. C'est une cible de surveillance petite et précise. Surveillez-la en continu, du point de vue du navigateur et faites atterrir l'alerte là où votre astreinte vit déjà. C'est exactement ce que fait CentralCSP depuis un seul en-tête : inventaire de scripts sur toutes les offres, règle d'origine à l'échelle du site dès Business, règles et preuves des pages de paiement dès Scale, et rien d'ajouté sur votre checkout. L'alerte n'est qu'une pièce du dispositif. [Ce dont votre checkout a réellement besoin](/fr/articles/csp-monitoring-for-ecommerce/) couvre le reste.

## Questions fréquentes

### Comment recevoir une alerte quand un nouveau script apparaît sur ma page de paiement ?

Faites remonter par l'en-tête Content-Security-Policy la liste des scripts que chaque navigateur visiteur exécute, alimentez un inventaire de scripts avec ces rapports, puis posez deux règles d'alerte : une règle « nouvelle origine de script » sur le site et, sur l'offre Scale, la règle « script non justifié » sur les pages que vous avez déclarées comme pages de paiement. Un script venu d'une origine jamais chargée par vos visiteurs déclenche la première, un script ou un hash que personne n'a justifié sur une page de paiement déclenche la seconde, à l'ingestion, vers Slack, Teams, Google Chat, Telegram, l'e-mail ou un webhook signé.

### Peut-on détecter Magecart sans installer d'agent sur le checkout ?

Oui. Les navigateurs savent rapporter l'URL et le hash SHA-256 de chaque script exécuté via le hash reporting de CSP. Le signal vient d'un simple en-tête HTTP : rien de nouveau ne s'exécute sur la page de paiement. Ajouter un agent JavaScript tiers sur un checkout est en soi une décision de supply chain et de périmètre PCI, précisément ce qu'on cherche à éviter.

### Comment éviter qu'une alerte parte à chaque déploiement légitime ?

Deux leviers. La règle « nouvelle origine de script » ignore vos propres renommages de bundle par construction : app.3f2a91.js qui devient app.8bc410.js sur la même origine n'est pas une nouvelle origine. Sur les pages de paiement déclarées, le module PCI accepte des règles d'auto-validation pour les motifs connus (une bibliothèque d'éditeur qui fait tourner son hash sur son URL habituelle), donc les rotations de routine n'atteignent jamais la file d'attente, et chaque règle porte un délai de refroidissement qui regroupe en un seul message ce qui se déclenche dans le même quart d'heure. Un script réellement nouveau déclenche toujours.

### Ces alertes suffisent-elles pour PCI DSS 11.6.1 ?

L'exigence 11.6.1 impose un mécanisme de détection d'altération sur les pages de paiement, exécuté au moins tous les sept jours. Une détection continue côté navigateur dépasse largement ce minimum. L'acceptation par les QSA varie, donc accompagnez les alertes d'un inventaire exportable et d'une chronologie des changements. La surveillance des pages de paiement, la justification des scripts et l'export de preuves relèvent de l'offre Scale (349,99 €/mois) et au-delà.