# Supervision CSP pour l’e-commerce : ce dont votre checkout a vraiment besoin

> Une boutique concentre son risque sur une page (le checkout) et une attaque (le skimming), pendant que le marketing injecte des scripts chaque semaine. Ce que la supervision CSP doit fournir : inventaire des scripts de paiement, alertes en minutes, connect-src appliqué, preuves PCI DSS.

- Canonical: https://info.centralcsp.com/fr/articles/csp-monitoring-for-ecommerce/
- Published: 2026-08-09
- Language: fr
- Publisher: CentralCSP (https://centralcsp.com)

Une boutique en ligne attend quatre choses de sa supervision CSP : un inventaire côté navigateur des scripts qui tournent sur les parcours de paiement, des alertes de changement limitées aux URL du checkout et livrées en quelques minutes, un `connect-src` appliqué qui coupe les destinations d’exfiltration et des preuves exportables pour PCI DSS 6.4.3 et 11.6.1. Le reste (contenu mixte, clickjacking) mérite d’être pris, mais ces quatre points sont ce qui sépare un skimmer des numéros de carte de vos clients.

## Pourquoi le modèle de menace d’une boutique tient sur une page

La plupart des sites pensent le XSS de façon abstraite. L’e-commerce n’a pas ce luxe : l’attaque qui vide le budget incident s’appelle le skimming, et elle vise un seul endroit. Le mode opératoire Magecart : compromettre un script qui tourne déjà sur votre checkout, ou en glisser un discrètement, puis copier les numéros de carte pendant la saisie. Rien ne casse. La conversion ne bouge pas. Nous avons détaillé le mécanisme dans [comment une CSP attrape une attaque Magecart](/fr/articles/catch-magecart-attack-csp/).

Pendant ce temps, le marketing élargit la surface d’attaque. Google Tag Manager, un pixel Meta, un pixel TikTok, un outil d’A/B testing, un widget d’avis clients, un tag d’affiliation, du session replay. GTM en particulier, c’est de l’injection de script à distance vendue comme un produit. Chacun de ces fournisseurs peut pousser du code sur vos pages sans déploiement, et sur beaucoup de boutiques le conteneur de tags change chaque semaine.

Voilà la tension du travail CSP en e-commerce : la page aux enjeux les plus élevés partage un template, un bundle ou un conteneur de tags avec les pages qui bougent le plus. Une politique pensée pour l’une casse sous l’autre.

## Commencer par un inventaire des scripts sur les chemins de paiement

Impossible de détecter un nouveau script sans savoir ce qui s’y trouvait hier, et un tableur tenu à la main était périmé avant d’être fini. Le [Script Inventory de CentralCSP](https://centralcsp.com/fr/platform/supply-chain/) construit la liste depuis le hash reporting de CSP : le navigateur de chaque visiteur rapporte les scripts qu’il exécute, avec origine, URL complète et hash d’intégrité SHA-256. Un en-tête, environ 5 minutes, pas de crawler et surtout pas d’agent, parce qu’ajouter le JavaScript d’un fournisseur sur la page que vous protégez est en soi une décision de supply chain.

Le côté navigateur compte plus ici qu’ailleurs. Un skimmer servi par un CDN compromis ne touche jamais vos serveurs, et les skimmers récents détectent les navigateurs headless : les crawlers reçoivent la version propre.

## Des alertes limitées au checkout, mesurées en minutes

Une revue hebdomadaire trouve le skimmer avec un demi-cycle de retard, en moyenne. Il vous faut deux règles. Une règle « nouvelle origine de script » sur la boutique et, sur les pages que vous avez déclarées comme pages de paiement (`/checkout/*`, les pages parentes de votre iframe de paiement), la règle « script non justifié » : une nouvelle URL de script ou un hash modifié que personne n’a justifié sur ces pages, et la notification part vers Slack, Teams, l’e-mail ou un webhook signé à l’ingestion. [L’alerting](https://centralcsp.com/fr/platform/alerting/) démarre avec Business (129,99 €/mois, alertes illimitées). Start n’en a pas : de quoi construire une politique, pas de quoi garder un checkout. La règle des pages de paiement, elle, fait partie du module PCI DSS de l’offre Scale (349,99 €/mois). La mise en place complète est dans [notre guide d’alerting checkout](/fr/articles/checkout-page-new-script-alerts/).

Ces règles survivent au contact du marketing grâce à ce qu’elles ne déclenchent pas. Une bibliothèque qui passe de `v4.2.1` à `v4.2.2` sur le même CDN n’est pas une nouvelle origine, et sur les pages de paiement une règle d’auto-validation pour la rotation de routine de cet éditeur la garde hors de la file d’attente. Un script venu d’une origine qui ne vous a jamais servi de code déclenche toujours, et tout ce qui apparaît sur une page de paiement hors des motifs que vous avez posés passe en file. Après ce filtre, ce qui reste est soit un tag ajouté sans prévenir, soit un incident.

## Appliquer connect-src, parce que le skimmer doit téléphoner à la maison

Des numéros de carte volés ne valent rien tant qu’ils restent sur votre page. Ils doivent partir, en général via `fetch` vers un domaine dont vous n’avez jamais entendu parler. Un `connect-src` appliqué, limité à vos propres API, à votre PSP et à vos endpoints analytics, transforme cet appel d’exfiltration en requête bloquée et en rapport de violation, même quand le code malveillant vient d’une origine que votre `script-src` autorise. Le checkout est la page où c’est le moins cher : elle parle légitimement à très peu de destinations. Complétez avec `form-action` pour qu’un formulaire détourné ne puisse pas poster ailleurs.

## Le volet PCI DSS, piège SAQ A compris

PCI DSS v4 rend tout cela obligatoire : la 6.4.3 exige un inventaire autorisé et justifié de chaque script des pages de paiement, la 11.6.1 une détection d’altération au moins tous les sept jours, et les deux sont exigées en évaluation depuis le 1er avril 2025. L’inventaire et les alertes ci-dessus sont le mécanisme. Le dossier de preuves (workflow de justification, justification métier par script, chronologie datée des changements, export CSV et PDF pour l’auditeur) est sur les plans Scale de CentralCSP (349,99 €/mois) et au-delà. 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/).

Une nuance surprend les marchands en iframe. La révision 2025 du SAQ A a retiré 6.4.3 et 11.6.1 de la liste des exigences, mais a ajouté un critère d’éligibilité : le site ne doit pas être vulnérable aux attaques par script. Or la page qui embarque l’iframe du PSP reste une cible (superposer un faux formulaire, remplacer l’iframe), donc « on utilise Stripe » clôt la discussion moins souvent que les marchands l’espèrent. Les lectures des QSA varient, nous avons vu les deux.

## Une politique qui survit au calendrier marketing

Si la plupart des CSP de boutiques meurent, c’est une affaire de process, pas de syntaxe. Construisez la politique depuis le trafic réel avec le [CSP Builder](https://centralcsp.com/fr/platform/csp-builder/) sur une fenêtre de rapports de 1 à 90 jours, relisez-la valeur par valeur, laissez-la en report-only jusqu’à ce que le flux soit calme, puis appliquez. Quand le marketing veut un nouveau tag, la revue tient en un coup d’œil à l’inventaire et une ligne de politique. Cette boucle, plus la règle d’origine dès Business et les règles de pages de paiement et les preuves PCI dès Scale, c’est tout le métier. CentralCSP fait l’ensemble depuis un seul en-tête HTTP, sans rien ajouter à votre checkout.

## Questions fréquentes

### Faut-il une CSP si mon formulaire de paiement est un iframe Stripe ou PSP ?

Oui, même si le périmètre se réduit. La page qui embarque l’iframe reste attaquable : un skimmer peut y superposer un faux formulaire ou remplacer l’iframe par le sien. La révision 2025 du SAQ A en tient compte : l’éligibilité dépend désormais du fait que le site ne soit pas vulnérable aux attaques par script, donc les marchands en iframe doivent toujours démontrer que la page d’intégration est protégée et surveillée.

### Comment empêcher les tags marketing de casser ou contourner ma CSP ?

Construisez la politique à partir du trafic de production réel plutôt que d’un tableur, laissez-la en report-only jusqu’à ce que le flux de violations soit calme, puis appliquez-la. Pour le churn permanent, la règle « nouvelle origine de script » ignore une montée de version CDN par construction (même origine, pas d’alerte), les règles d’auto-validation de vos pages de paiement déclarées absorbent les rotations de hash de routine d’un éditeur, un script réellement nouveau déclenche toujours, et la revue d’un nouveau tag prend quelques minutes, pas un comité de changement.

### Quelles directives CSP comptent le plus pour une boutique en ligne ?

script-src contrôle ce qui peut s’exécuter, connect-src contrôle où les données peuvent partir. Sur un checkout, connect-src est la directive sous-estimée : un skimmer qui parvient à tourner doit encore exfiltrer les numéros de carte quelque part, et un connect-src appliqué, limité à votre PSP et à vos endpoints connus, bloque cet appel sortant. Ajoutez form-action contre le détournement de formulaire.

### La supervision CSP suffit-elle pour PCI DSS 6.4.3 et 11.6.1 sur une boutique ?

La correspondance est directe. L’exigence 6.4.3 demande un inventaire autorisé et justifié des scripts des pages de paiement, la 11.6.1 une détection d’altération au moins tous les sept jours. L’inventaire côté navigateur et les alertes continues couvrent les deux mécanismes. Le dossier de preuves exportable (workflow de justification, chronologies de changements, export CSV et PDF) est disponible sur les plans Scale de CentralCSP (349,99 €/mois) et au-delà.