PCI DSS : inventoriez et surveillez les scripts de vos pages de paiement
Depuis mars 2025, PCI DSS 4.x impose de nouvelles exigences directement liées à votre surface d’attaque web : inventorier et autoriser les scripts exécutés sur les pages de paiement, et détecter toute modification non autorisée. La réponse du standard aux attaques par e-skimming — et un terrain où la surveillance continue change tout.
.svg)
PCI DSS 4.x en bref
Ce qui a changé avec PCI DSS 4.x,
en trois points
- Le standard mondial des données de carte Toute organisation qui stocke, traite ou transmet des données de cartes de paiement est concernée : e-commerçants, retail, plateformes, prestataires de paiement, partout en Europe et au-delà.
- Deux exigences ciblent désormais vos pages de paiement Obligatoires depuis le 31 mars 2025 : l’exigence 6.4.3 impose d’inventorier, d’autoriser et de justifier chaque script exécuté sur les pages de paiement ; l’exigence 11.6.1 impose un mécanisme de détection des modifications non autorisées de ces pages (contrôles au moins hebdomadaires).
- La cible : l’e-skimming Ces exigences répondent aux attaques de type Magecart : un script tiers compromis (widget, tag marketing, librairie) qui exfiltre silencieusement les données de carte directement depuis le navigateur du client. Le serveur n’est pas touché ; la page, si.
Là où Purplemet intervient
Nous observons ce que vos pages de paiement exécutent réellement
Les exigences 6.4.3 et 11.6.1 posent toutes deux la même question préalable : savez-vous, à tout instant, quels scripts et technologies vos pages exposées exécutent réellement ? C’est exactement ce que Purplemet observe — de l’extérieur, comme un attaquant ou un auditeur le ferait.
- Inventaire des scripts et technologies (exigence 6.4.3) Purplemet inventorie en continu les technologies présentes sur vos pages exposées : scripts, librairies JavaScript, tags tiers, frameworks — et leurs versions. L’inventaire exigé par le standard cesse d’être un document déclaratif mis à jour à la main : il reflète ce qui est réellement servi aux navigateurs de vos clients.
- Détection des changements (exigence 11.6.1) Chaque évolution de ce que vos pages exposent — script ajouté, composant modifié, version changée — est détectée au fil de l’eau. Un tag tiers apparu sans autorisation, une librairie modifiée : vous le savez sans attendre le prochain contrôle hebdomadaire ni le prochain audit.
- Veille sur les composants vulnérables Au-delà des pages de paiement, PCI DSS attend une gestion des vulnérabilités sur l’ensemble du périmètre. Purplemet confronte en continu l’inventaire de vos applications exposées aux vulnérabilités publiées (CVE) : vous savez le jour même si un composant est concerné.
- Cadrer le périmètre Le périmètre PCI DSS ne se limite pas aux pages que vous connaissez : une page de paiement oubliée, un environnement de test exposé, un sous-domaine hérité peuvent y entrer à votre insu. Purplemet découvre ce que votre organisation expose réellement — et vous aide à délimiter honnêtement le périmètre à défendre.
Questions fréquentes sur PCI DSS et le Web ASM
Purplemet peut-il valider ma conformité PCI DSS ?
Non. La validation relève des évaluateurs qualifiés (QSA) et les scans trimestriels exigés par le standard relèvent des prestataires approuvés (ASV), référencés par le PCI Security Standards Council. Purplemet n’est ni l’un ni l’autre : c’est un outil de surveillance continue qui alimente plusieurs exigences du standard — notamment l’inventaire des scripts des pages de paiement et la détection des changements.
Que demandent les exigences 6.4.3 et 11.6.1 de PCI DSS ?
L’exigence 6.4.3 impose de maintenir un inventaire de tous les scripts exécutés sur les pages de paiement, avec autorisation et justification de chacun, et une assurance de leur intégrité. L’exigence 11.6.1 impose un mécanisme détectant les modifications non autorisées de ces pages, avec des contrôles au moins hebdomadaires. Toutes deux sont obligatoires depuis le 31 mars 2025 et visent les attaques par e-skimming. Leur applicabilité exacte dépend de votre canal d’acceptation — à valider avec votre QSA.
Qu’est-ce que l’e-skimming (Magecart) ?
Une attaque où un script chargé par votre page de paiement — souvent un composant tiers légitime compromis — capture les données de carte directement dans le navigateur du client et les exfiltre vers l’attaquant. Le serveur n’est pas compromis ; c’est la chaîne de scripts de la page qui l’est. D’où l’exigence d’inventorier et de surveiller en continu ce que vos pages exécutent réellement.