Guide de sécurité des pages de paiement

Protection contre les scripts côté client et Magecart : guide PCI DSS

Tout script capable de lire une page de paiement, toute modification du gestionnaire de balises et tout en-tête de réponse ayant un impact sur la sécurité font partie de la surface d'attaque de la page de paiement.

Publié le: 15 juil. 2026
Mis à jour le: 15 juil. 2026
Temps de lecture: 14 min de lecture

Sur cette page

L'e-skimming peut provenir d'une plateforme compromise, d'un compte d'administration, de JavaScript tiers, d'une dépendance de chaîne d'approvisionnement ou d'une XSS. Traitez les scripts et en-têtes reçus par le navigateur comme une surface de production contrôlée, et non comme un résultat non suivi des outils marketing ou de déploiement.

Overview

Résultat attendu

Établissez un programme pour les pages de paiement qui autorise les scripts, vérifie leur intégrité, détecte les altérations observées par le navigateur, préserve les preuves utiles et prend en charge une réponse ciblée aux incidents.

Comprendre les résultats attendus par PCI DSS 4.0.1

Les exigences 6.4.3 et 11.6.1 sont effectives depuis le 31 mars 2025. Pour les scripts de page de paiement chargés et exécutés dans le navigateur d'un consommateur, l'organisation doit confirmer leur autorisation, garantir leur intégrité et maintenir un inventaire avec une justification métier ou technique. Elle doit aussi détecter et alerter sur les modifications non autorisées des en-têtes HTTP ayant un impact sur la sécurité et du contenu des scripts de page de paiement tels que le navigateur les reçoit. PCI DSS définit des résultats, et non un produit CSP, SRI, edge ou de monitoring obligatoire.

Boucle de contrôle de la page de paiement

Référence approuvée
Chaque script, origine, objectif, propriétaire et date de revue est enregistré.
Diffusion contrôlée
Les changements de build, gestionnaire de balises, en-têtes et edge suivent le contrôle des changements.
Observation du navigateur
Les en-têtes, scripts, redirections et hachages sont comparés à l'état approuvé.
Alerte et réponse
Les différences non autorisées sont contenues en préservant les preuves.

Un inventaire fiable suit la page livrée au navigateur à travers l'approbation, la vérification d'intégrité, la détection d'altération et la réponse.

Les changements de page de paiement observés par le navigateur ferment la boucle de contrôle

La page reçue par le navigateur est le point de contrôle : un build approuvé seul ne peut pas prouver que les scripts, redirections et en-têtes sont restés inchangés pendant la diffusion.

Telecharger:PNG SVG

Construire un inventaire de scripts que le navigateur peut prouver

Inventoriez les scripts first-party et tiers, les chargements dynamiques, les règles du gestionnaire de balises, les iframes, les URL finales après redirection, le propriétaire, l'objectif, l'approbation, le hachage ou la version lorsqu'ils sont utilisables, le périmètre de page, la justification de l'accès aux données et le chemin de retour arrière. Une liste de dépendances de build ne suffit pas, car un gestionnaire de balises ou un fournisseur peut modifier le code livré au navigateur en dehors du dépôt de l'application.

Contrôle	Ce qu'il fait	Ce qu'il ne prouve pas
CSP	Limite les sources autorisées de scripts, connexions, formulaires, cadres et objets	Que chaque script autorisé est approuvé ou inchangé
SRI	Ancre une ressource externe stable à une empreinte attendue	Qu'une URL de fournisseur mutable ou un programme de gestionnaire de balises est sûr
Détection d'altération par le navigateur	Compare les en-têtes et contenus livrés à la référence approuvée	La cause racine ou le périmètre d'exposition des données à elle seule
Diffusion d'en-têtes à l'edge	Rend la politique cohérente et observable	La conformité complète de la page de paiement à elle seule

Exemple d'enregistrement d'inventaire de script

page=/checkout
script=https://static.example.com/checkout.8f3a.js
owner=payments-platform purpose=payment-form release=2026.07.15
integrity=approved-hash change_ticket=SEC-184
browser_check=pass csp_origin=allowlisted review_due=2026-10-15

Utiliser CSP et SRI en défense en profondeur

Utilisez une CSP propre au paiement, livrée par HTTP, avec des politiques délibérées pour script-src, connect-src, form-action, frame-src, frame-ancestors, base-uri et object-src. Commencez en mode rapport uniquement, éliminez les violations légitimes, puis appliquez-la. Appliquez SRI aux scripts externes stables lorsque le hachage attendu et le comportement CORS peuvent être contrôlés. N'ajoutez pas aveuglément des nonces ou des attributs d'intégrité à l'edge : l'insertion automatique de nonces peut autoriser des scripts injectés par un attaquant.

Détecter les altérations et répondre de façon ciblée

Comparez la page reçue par un navigateur à une référence approuvée : HTML, URL et hachages des scripts, redirections, contenu du gestionnaire de balises et en-têtes ayant un impact sur la sécurité. Alertez sur les ajouts, suppressions, origines inattendues, SRI modifiés ou destinations de connexion de paiement modifiées. Conservez les en-têtes, un instantané de page, les hachages, l'horodatage, l'identifiant de version et la décision d'alerte, mais jamais le PAN, le CVV, les valeurs de formulaire, les jetons ou les chaînes de requête sensibles.

Troubleshooting

Anti-modèles de sécurité des pages de paiement

Considérer le déploiement de CSP ou SRI comme une preuve de conformité PCI DSS.
Garder du code d'analytique, d'expérimentation, de chat ou de marketing au paiement sans justification propre au paiement.
Détecter uniquement les dépendances au moment du build plutôt que la page livrée au navigateur.
Journaliser des corps de formulaire ou des données de paiement pendant l'enquête sur une alerte de script.

Guides connexes

Références faisant autorité

Préparez les changements de page de paiement à produire des preuves

Optimi peut vous aider à aligner la politique edge, les contrôles observés par le navigateur et les preuves d'incident autour des scripts et en-têtes qui servent le paiement.

Examiner la sécurité de la page de paiement