PCI DSS v4.0.1 : les exigences techniques,
par numéro

Le 31 mars 2025, une série d'exigences PCI DSS sont passées du statut de bonne pratique à celui d'obligation ferme. Parmi elles, l'inventaire des scripts d'une page de paiement (6.4.3) et la détection de leur modification (11.6.1) : deux contrôles nés directement des attaques Magecart. C'est le meilleur symptôme de ce qu'est devenu le standard. PCI DSS traîne une réputation de checklist administrative, un questionnaire qu'on remplit une fois l'an. La version 4.0.1 dit l'inverse : elle numérote des contrôles techniques précis, avec des cadences et des méthodes, et c'est par ces numéros qu'un assesseur les vérifie.

Cet article lit les exigences qui touchent une équipe technique, une par une, par numéro exact de la v4.0.1 : le scan de vulnérabilités (11.3), le test d'intrusion (11.4), les scripts de paiement (6.4.3 et 11.6.1) et la gestion du périmètre (12.5). Les libellés cités viennent du texte officiel du PCI Security Standards Council. Une précision d'emblée, parce qu'elle change la lecture de toute la suite : own2pwn n'est pas un ASV agréé, et un scan EASM n'est pas un scan ASV. On dira à chaque exigence ce qu'un pentest peut établir, et ce qu'il ne remplace pas.

PCI DSS v4.0.1, la version qui muscle le volet technique

PCI DSS (Payment Card Industry Data Security Standard) encadre le stockage, le traitement et la transmission des données de carte de paiement. Douze exigences de haut niveau, réparties en six objectifs, avec sous chacune des dizaines de sous-exigences testables. La v4.0.1 a introduit une "approche personnalisée" (customized approach) qui autorise à atteindre un objectif de sécurité autrement que par la mesure prescrite, mais elle a surtout ajouté des contrôles techniques nouveaux, dont plusieurs n'étaient qu'une recommandation dans la v4.0.

Pour une équipe qui construit et exploite un site marchand, quatre familles d'exigences pèsent le plus lourd au quotidien. Elles reviennent dans presque tous les audits, et ce sont celles qu'on détaille ici.

On les prend dans cet ordre. Chacune a sa cadence propre, et surtout son exécutant attendu : certaines exigent un tiers agréé, d'autres seulement un testeur indépendant, d'autres encore relèvent de vos propres processus internes. Confondre les trois est la première cause de rejet en audit.

11.3.2 : le scan de vulnérabilités externe passe par un ASV agréé

L'exigence 11.3 impose deux régimes de scan distincts. Le 11.3.1 couvre les scans internes, réalisés au moins une fois tous les trois mois et après tout changement significatif, avec correction des vulnérabilités à haut risque et rescan pour confirmer. Vous pouvez les exécuter vous-même, avec l'outil de votre choix. C'est le 11.3.2 qui pose la contrainte forte : le scan de vulnérabilités externe doit être effectué "au moins une fois tous les trois mois" et "par un PCI SSC Approved Scanning Vendor (ASV)", avec un rapport qui satisfait les exigences de scan réussi du programme ASV.

Un ASV est une société agréée par le PCI SSC, dont l'outil et le processus ont été validés par le conseil. Ce n'est pas un label qu'on s'auto-décerne. own2pwn n'est pas ASV : nous ne produisons pas d'attestation de scan ASV, et notre plateforme n'en tient pas lieu. Il faut le dire nettement, parce que la confusion est commode. Un outil de surveillance de la surface d'attaque externe (EASM) scanne lui aussi des actifs exposés et remonte des vulnérabilités par corrélation de bannières et de versions. Mais un EASM n'est pas un scan ASV au sens de 11.3.2 : il n'émet pas le rapport normalisé attendu et n'engage pas un fournisseur agréé. Il aide à préparer le terrain, à réduire le nombre de trouvailles avant le passage de l'ASV, pas à cocher la case.

11.4 : le test d'intrusion, de la méthodologie 11.4.1 au retest 11.4.4

Le test d'intrusion est l'exigence 11.4, et elle se déplie en sous-exigences qu'un assesseur vérifie point par point. Tout commence par le 11.4.1, qui impose une méthodologie documentée et appliquée. Ce n'est pas une formalité : le texte énumère ce qu'elle doit contenir, dont une approche reconnue du secteur, la couverture de tout le périmètre du CDE et des systèmes critiques, des tests depuis l'intérieur et l'extérieur, la validation des contrôles de segmentation, et une phase applicative couvrant au minimum les vulnérabilités listées à l'exigence 6.2.4. La méthodologie exige aussi de conserver les résultats de test et de remédiation pendant au moins 12 mois.

Viennent ensuite le 11.4.2 (test interne) et le 11.4.3 (test externe), tous deux "au moins une fois tous les 12 mois et après tout changement significatif d'infrastructure ou d'application". Le 11.4.3 précise le profil du testeur : une ressource interne qualifiée ou un tiers externe qualifié, avec une indépendance organisationnelle, et il ajoute une phrase décisive, "pas nécessairement un QSA ou un ASV". Autrement dit, le pentest PCI n'a pas à venir d'un fournisseur labellisé, il doit venir d'un testeur indépendant de l'équipe qui gère l'environnement. C'est exactement le cadre d'un pentest web en boîte noire commandé à un prestataire externe, ou d'un pentest en boîte blanche quand l'accès au code sert la phase applicative de 6.2.4.

Le 11.4.4 ferme la boucle : les vulnérabilités exploitables et faiblesses trouvées pendant le test doivent être corrigées selon l'évaluation du risque, puis le test est répété pour vérifier que la correction tient. Un pentest sans retest ne satisfait pas l'exigence. C'est pour cette raison que le retest est inclus dans les missions own2pwn : sans lui, le livrable ne prouve rien à un assesseur. Enfin le 11.4.5 demande, quand la segmentation isole le CDE, de tester ces contrôles de segmentation au moins tous les 12 mois. Un pentest own2pwn se place donc en support de 11.4.3 (le test externe), conduit selon une méthodologie qui matérialise 11.4.1, avec la correction et le retest de 11.4.4.

Lisez la colonne de droite : la cadence "12 mois + changement significatif" revient partout. Un site marchand actif change souvent, et chaque refonte du tunnel de paiement rouvre l'obligation de tester. La conformité n'est pas un jalon annuel, c'est un rythme calé sur vos mises en production.

6.4.3 et 11.6.1 : les scripts de la page de paiement, ou le problème Magecart

C'est la nouveauté la plus concrète de la v4.0.1, et elle vise une classe d'attaques bien réelle : le web skimming, popularisé sous le nom de Magecart. Le principe est simple et redoutable. La page de paiement charge des scripts tiers (analytics, chat, gestion de tags, widgets). Si l'un d'eux est compromis, l'attaquant injecte un skimmer qui recopie le numéro de carte saisi vers un serveur qu'il contrôle, pendant que la transaction se déroule normalement pour le client. Rien ne casse, rien ne s'affiche. L'attaque de British Airways en 2018 en est le cas d'école : un script de la page de paiement modifié a exfiltré les données de centaines de milliers de clients, et le régulateur britannique (ICO) a sanctionné la compagnie de 20 millions de livres en octobre 2020.

L'exigence 6.4.3 répond à ce risque côté prévention. Elle demande que "tous les scripts de la page de paiement chargés et exécutés dans le navigateur du consommateur" soient gérés selon trois éléments : une méthode pour confirmer que chaque script est autorisé, une méthode pour assurer l'intégrité de chaque script, et un inventaire de tous les scripts avec une justification métier ou technique écrite. La note d'applicabilité précise que cela couvre les scripts chargés depuis votre environnement comme ceux venant de tiers et de quatrièmes parties. C'est frontalement un enjeu de sécurité de la chaîne d'approvisionnement logicielle : le script que vous n'avez pas écrit, mais que vous exécutez chez vos clients.

Techniquement, l'intégrité passe souvent par Subresource Integrity (SRI), où l'empreinte du script est figée dans la balise, et par une Content Security Policy qui restreint les origines autorisées. On calcule l'empreinte à autoriser avant de la coller :

# 6.4.3 : calculer l'empreinte SRI d'un script avant de l'autoriser
curl -sS https://cdn.exemple.tld/checkout.js \
  | openssl dgst -sha384 -binary \
  | openssl base64 -A
# -> renvoie l'empreinte a coller dans l'attribut integrity ci-dessous

<!-- integrite figee : le navigateur refuse le script si l'empreinte differe -->
<script src="https://cdn.exemple.tld/checkout.js"
        integrity="sha384-<empreinte_calculee>"
        crossorigin="anonymous"></script>

<!-- CSP restreignant les origines de scripts de la page de paiement -->
<!-- Content-Security-Policy: script-src 'self' https://cdn.exemple.tld -->

L'exigence 11.6.1 complète 6.4.3 côté détection. Elle impose un "mécanisme de détection de changement et d'altération" qui alerte en cas de modification non autorisée des en-têtes HTTP à impact sécurité et du contenu des scripts de la page de paiement, tels que reçus par le navigateur du client, avec une évaluation réalisée au moins une fois par semaine. Autorisation et inventaire d'un côté, détection de dérive de l'autre. Ces deux exigences étaient des bonnes pratiques "until 31 March 2025" dans les notes du standard, et sont obligatoires depuis. C'est un contrôle côté client, dans le navigateur : ni un pentest, ni un EASM, ni un scan ASV ne le remplacent.

12.5.2 : documenter et confirmer le périmètre (le scope)

Toute la conformité PCI DSS repose sur une question préalable : quel est le périmètre concerné ? L'exigence 12.5.1 demande un inventaire des composants du système inclus dans le CDE (Cardholder Data Environment). Le 12.5.2 va plus loin : "le périmètre PCI DSS est documenté et confirmé par l'entité au moins une fois tous les 12 mois et à chaque changement significatif de l'environnement concerné". La validation inclut, au minimum, l'identification de tous les flux de données pour les différentes étapes de paiement, la mise à jour des schémas de flux de données, et l'identification de toutes les localisations où les données de compte sont stockées, traitées et transmises, y compris hors du CDE actuellement défini.

C'est le point où un EASM apporte une vraie valeur, à condition de bien poser sa limite. Un périmètre déclaré à froid dans un tableur oublie toujours quelque chose : un sous-domaine de préproduction resté en ligne, un actif racheté avec une filiale, une API exposée par erreur. La surveillance continue de la surface d'attaque externe remonte ces actifs que l'inventaire manuel ne voit pas, et signale les expositions qui peuvent toucher le CDE ou s'y connecter. Elle nourrit donc 12.5.1 et 12.5.2. Mais, encore une fois, c'est une aide à la découverte et à la tenue de l'inventaire, pas l'attestation de scan de 11.3.2 ni le test de 11.4. La même prudence vaut pour les fuites de secrets exposées publiquement : un identifiant d'accès au CDE qui traîne dans un dépôt public élargit votre périmètre sans que vous l'ayez décidé.

SAQ A, A-EP ou D : le bon questionnaire d'auto-évaluation

La plupart des marchands ne se font pas auditer par un QSA mais remplissent un SAQ (Self-Assessment Questionnaire). Le bon SAQ dépend entièrement de la façon dont la carte transite par votre infrastructure, et ce choix détermine quelles exigences ci-dessus vous concernent réellement. Se tromper de SAQ, c'est soit s'imposer des contrôles inutiles, soit passer à côté d'obligations qui s'appliquent.

La ligne SAQ A-EP est celle qui piège le plus. Beaucoup de sites croient relever du SAQ A parce qu'ils "utilisent un prestataire de paiement", alors que leur page assemble elle-même le formulaire ou charge un script qui touche le champ de carte : ils sont en réalité en A-EP, donc pleinement soumis à 6.4.3 et 11.6.1. Le SAQ A, en v4.0.1, a vu ses critères d'éligibilité resserrés précisément à cause du web skimming, avec une attestation spécifique demandée au marchand sur le fait que son site n'expose pas la page de paiement à ce type d'attaque. Le SAQ D, lui, est le régime complet, celui où le test d'intrusion de 11.4 s'applique sans ambiguïté.

PCI DSS et NIS2 : des contrôles techniques qui se recouvrent

Si votre organisation est aussi concernée par la directive NIS2, une bonne partie du travail technique se mutualise. Les mesures de gestion des risques de l'article 21.2 de NIS2, notamment la sécurité de l'acquisition et du développement, la gestion et la divulgation des vulnérabilités, et l'évaluation de l'efficacité des mesures, se prouvent avec les mêmes livrables qu'une bonne partie de PCI DSS : un test d'intrusion documenté, un plan de remédiation, un retest. Un même pentest peut alimenter l'exigence 11.4.3 de PCI DSS et le volet technique d'un audit NIS2, à condition que le périmètre soit défini pour couvrir les deux.

Les deux cadres ne se confondent pas pour autant. PCI DSS est prescriptif, chiffré, cadencé sur des exigences numérotées, et limité aux données de carte. NIS2 est une obligation de résultat sur un périmètre plus large, sans numéro de contrôle à cocher. Mais quand on décompose leurs attentes techniques, le chevauchement est réel : inventaire des actifs, gestion continue des vulnérabilités, test indépendant, correction prouvée. Bâtir une fois ces processus sert les deux réglementations, plutôt que d'empiler deux dossiers parallèles.

À retenir

• Le scan externe 11.3.2 est trimestriel et exige un ASV agréé. own2pwn n'est pas ASV, et un EASM n'est pas un scan ASV : ces outils préparent le terrain, ils ne cochent pas la case.
• Le test d'intrusion 11.4 se décompose en méthodologie (11.4.1), test interne et externe (11.4.2, 11.4.3), correction et retest (11.4.4). Le testeur externe doit être indépendant, mais n'a pas besoin d'être QSA ou ASV.
• Les scripts de paiement (6.4.3 : autorisation, intégrité, inventaire ; 11.6.1 : détection au moins hebdomadaire) sont obligatoires depuis le 31 mars 2025. Ils visent le web skimming façon Magecart.
• Le périmètre 12.5.2 se confirme tous les 12 mois et à chaque changement. Un EASM aide à découvrir les actifs oubliés, sans remplacer le scan ni le pentest.
• Le choix du SAQ (A, A-EP, D) détermine les exigences qui s'appliquent. Beaucoup de sites en A-EP se croient à tort en A et négligent 6.4.3 et 11.6.1.

Le test d'intrusion de l'exigence 11.4.3, avec sa méthodologie, sa correction et son retest, est la brique où own2pwn intervient concrètement dans un dossier PCI DSS. Si vous cadrez la conformité de votre tunnel de paiement, on peut en parler côté technique via un pentest web ou directement sur la page contact. Pour le scan ASV trimestriel, en revanche, adressez-vous à un fournisseur agréé : c'est une contrainte de la norme, pas un choix.

Questions fréquentes sur PCI DSS v4.0.1