Les exigences PCI DSS 4.0.1 6.4.3 et 11.6.1 gouvernent les scripts et en-têtes HTTP de vos pages de paiement. 6.4.3 vous impose d'inventorier, d'autoriser et d'assurer l'intégrité de chaque script. 11.6.1 vous impose de détecter et d'alerter sur les changements non autorisés des scripts et en-têtes de sécurité de cette page. Les deux sont obligatoires depuis 2025-03-31. Ce guide décompose chaque clause, ce qu'elle signifie pour la page en production, et la preuve spécifique qu'un QSA attend qu'elle produise.
Ces deux exigences existent à cause du e-skimming. Les attaquants de type Magecart ne compromettent pas votre serveur. Ils modifient un script que le navigateur charge, puis capturent les données du titulaire de carte directement depuis le formulaire pendant que l'utilisateur les saisit. Un iframe de processeur ne couvre pas la page qui l'encadre. cside vit dans cet angle mort exact : elle enregistre chaque script que de vrais navigateurs exécutent sur la page de paiement, capture l'autorisation et signale les changements d'intégrité et d'en-têtes au moment où ils se produisent.
Ce que l'exigence 6.4.3 demande réellement
6.4.3 pose trois obligations pour chaque script de page de paiement. Lisez chacune comme une clause distincte, parce qu'un QSA le fera :
- Une méthode confirme que chaque script est autorisé avant de se charger ou de s'exécuter.
- Une méthode assure l'intégrité de chaque script.
- Un inventaire des scripts est maintenu avec une justification écrite de pourquoi chacun est nécessaire.
« Autorisé » et « nécessaire » sont les deux mots qui font trébucher les équipes. L'autorisation est une décision enregistrée : un approbateur nommé a signé que ce script peut tourner sur une page dans le périmètre des données de carte. La justification est la raison business pour laquelle il existe. Un pixel de tracking que le marketing a ajouté le trimestre dernier n'a généralement ni l'un ni l'autre, ce qui est exactement le type de constat que 6.4.3 fait remonter.
Le périmètre est plus large que le code first-party. Le contrôle couvre chaque script que le navigateur exécute sur la page : vos propres bundles, les SDKs tiers et les scripts de quatrième partie que ces vendors tirent à l'exécution. Un tag manager qui injecte trois scripts supplémentaires après le chargement de la page, c'est trois entrées de plus dans votre inventaire, et ces entrées changent sans déploiement de votre côté.
Le PCI SSC liste les hashes Subresource Integrity (SRI) et Content-Security-Policy comme exemples de mécanismes d'intégrité. Ils tiennent pour les assets statiques. Ils cassent dès qu'un script est dynamique. Un tag d'analytics ou un outil A/B qui se met à jour légitimement invalide le hash, donc un SRI épinglé bloque soit une bonne mise à jour, soit est retiré et ne protège plus rien. La Content Security Policy a la même limite : elle ne peut pas garantir ce que fait un script autorisé à l'exécution. C'est pourquoi l'intégrité pour de vraies pages de paiement doit être évaluée sur ce qui s'est exécuté, pas sur un hash fixé au build.
Ce que l'exigence 11.6.1 demande réellement
11.6.1 est un contrôle de détection, pas de gestion. Elle exige un mécanisme de détection de changement et d'altération qui fait deux choses :
- Alerte le personnel sur toute modification non autorisée (y compris les indicateurs de compromission, changements, ajouts et suppressions) des en-têtes HTTP et du contenu des pages de paiement tels que reçus par le navigateur du consommateur.
- Évalue les en-têtes et le contenu reçus à une fréquence fixée par votre analyse de risque ciblée sous l'exigence 12.3.1, ou au moins une fois tous les sept jours.
La formule « tels que reçus par le navigateur du consommateur » porte l'exigence. 11.6.1 ne demande pas ce que votre CDN a servi ni ce que votre dépôt contient. Elle demande ce que le navigateur a rendu, après chaque redirection, injection et modification à l'exécution. Un skimmer lit navigator.webdriver, les propriétés d'automatisation manquantes et l'absence d'interaction réelle pour reconnaître un scanner, puis lui sert du code propre et le payload à un humain. Un contrôle qui ne voit que la version scannée ne se déclenche jamais.
Les en-têtes HTTP sont dans le périmètre parce qu'ils sont une surface d'attaque, pas un détail de config. Un en-tête Content-Security-Policy affaibli ou retiré permet le chargement d'un script malveillant que la politique était censée bloquer. 11.6.1 veut que vous remarquiez que l'en-tête a changé, et que vous le remarquiez sur la réponse livrée, pas dans votre config d'origine.
Comment les deux exigences se répartissent le travail
6.4.3 régit ce que vous autorisez ; 11.6.1 régit ce qui s'est passé sur la page.
| Question | Exigence | Ce qu'elle gouverne | Mode d'échec qu'elle attrape |
|---|---|---|---|
| Quels scripts sont autorisés ici, et pourquoi ? | 6.4.3 | Autorisation, justification, intégrité, inventaire | Un script non approuvé ou non documenté dans le périmètre |
| La page ou ses en-têtes ont-ils changé sans approbation ? | 11.6.1 | Détection et alerte sur les changements de scripts et d'en-têtes | Une altération en direct que l'inventaire n'a pas vue |
| À quelle fréquence vérifions-nous la page livrée ? | 11.6.1 + 12.3.1 | Fréquence, avec un plancher de sept jours | Des vérifications périmées qui manquent les changements transitoires |
Traitez-les comme une boucle, pas comme deux projets. Un inventaire sans détection en direct est une liste qui devient obsolète dès qu'un vendor pousse une mise à jour. Une détection sans inventaire produit des alertes que personne ne peut trier, parce qu'il n'existe pas de baseline de ce que « autorisé » signifie.
Les preuves que chaque contrôle doit produire
Un QSA évalue la conformité à partir d'artefacts. Mappez chaque clause à l'enregistrement qu'elle génère afin de pouvoir remettre exactement ce qu'il demande.
| Clause | Artefact de preuve | Ce qu'il doit montrer |
|---|---|---|
| Inventaire 6.4.3 | Inventaire des scripts lié aux pages dans le périmètre | L'URL, le propriétaire et la dernière version vue de chaque script |
| Autorisation 6.4.3 | Enregistrement d'approbation par script | Qui l'a approuvé, quand, et les données qu'il touche |
| Justification 6.4.3 | Note de raison business par script | Pourquoi le script est nécessaire sur une page de paiement |
| Intégrité 6.4.3 | Historique d'intégrité | Comment chaque script est confirmé non altéré dans le temps |
| Détection 11.6.1 | Journal de changements avec alertes | Timestamp, diff, page et qui a été notifié |
| Évaluation des en-têtes 11.6.1 | Historique des en-têtes par page | Valeurs des en-têtes de sécurité et changements entre les chargements |
| Fréquence 11.6.1 | Analyse de risque + cadence de vérification | La justification 12.3.1 et la preuve que les vérifications ont tourné |
L'artefact qui manque le plus souvent aux équipes est l'historique d'intégrité et l'historique d'en-têtes dans le temps. Un instantané unique prouve que la page était propre une fois. Un QSA qui évalue 11.6.1 veut une preuve que vous auriez repéré un changement : un enregistrement horodaté sur de nombreux chargements réels de page, pas une capture d'écran.
Pourquoi un processeur ne ferme pas ça pour vous
Une supposition courante est qu'héberger les champs de paiement dans un iframe Stripe, Adyen ou Braintree pousse 6.4.3 et 11.6.1 sur le processeur. Ce n'est pas le cas. L'iframe est sandboxé, mais la page marchande qui l'encadre ne l'est pas. Votre analytics, votre outil A/B, votre session-replay et vos widgets de chat tournent tous dans le même contexte navigateur de niveau supérieur, et un script là peut lire le DOM, superposer un faux champ par-dessus l'iframe ou rediriger le formulaire au moment du submit. La mise à jour SAQ A de janvier 2025 a restreint l'éligibilité parce que bien peu de pages de paiement réelles sont exemptes de scripts tiers, et elle a ajouté un critère demandant de confirmer que votre site n'est pas susceptible aux attaques par scripts, ce qui est difficile à prouver sans surveillance. Les exigences restent attachées à la page que vous servez.
Pourquoi la menace est de plus en plus difficile à scanner
La raison pour laquelle 11.6.1 insiste sur la page livrée est que l'outing de l'attaquant est conçu pour battre tout ce qui n'est pas réel. Les navigateurs headless et instrumentés fuient : un flag navigator.webdriver, des objets runtime chrome manquants, des artefacts Runtime du Chrome DevTools Protocol et un timing impossible marquent une session comme non humaine. Les skimmers fingerprint ces signaux et restent dormants face aux crawlers et vérifications synthétiques.
L'outing d'évasion a aussi progressé dans l'autre sens. Le rapport de recherche de cside sur le futur de la sécurité web a constaté que playwright-stealth, de l'automatisation réglée pour supprimer ces fuites, était environ dix fois plus utilisé à la fin de 2025. La conclusion pratique pour 6.4.3 et 11.6.1 : l'intégrité et la détection de changements doivent tourner là où les données du titulaire de carte sont réellement saisies, dans la vraie session navigateur, pas depuis un point d'observation externe qu'un script évasif peut identifier et esquiver.
Comment cside produit cette preuve à la couche navigateur
cside instrumente la page de paiement dans de vrais navigateurs, qui est la surface que les deux exigences visent.
- Pour 6.4.3, elle capture l'inventaire complet des scripts, y compris les scripts de quatrième partie que les vendors tirent à l'exécution, enregistre l'autorisation et la justification à côté de chaque entrée, et conserve un historique d'intégrité pour prouver qu'un script est resté intact entre les versions.
- Pour 11.6.1, elle surveille le contenu des scripts et les en-têtes HTTP de sécurité sur la page livrée, les diff entre les chargements et alerte sur les changements non autorisés, avec un enregistrement horodaté qui répond à la question de fréquence 12.3.1 sans extraction manuelle hebdomadaire.
- Elle fait aussi remonter le payload runtime de chaque script et associe le comportement des scripts aux signaux d'appareil, d'IP réelle et de VPN/proxy, pour qu'un changement signalé arrive avec du contexte plutôt qu'un simple mismatch de hash.
Parce qu'elle observe ce qui s'est exécuté plutôt que ce qu'on a montré à un scanner, cside capture la même preuve navigateur qu'un attaquant e-skimming tente de cacher. Cela aligne le workflow de conformité sur la menace réelle. Pour le déploiement opérationnel et la vue de reporting QSA, les guides ci-dessous vont plus loin.
Lectures complémentaires sur cside
- Comment se conformer à PCI 6.4.3 et 11.6.1
- Ce que les QSAs recherchent en évaluant 6.4.3 et 11.6.1
- Comparaison de solutions pour PCI DSS 6.4.3 et 11.6.1
- Qu'est-ce que la client-side security
- cside PCI Shield
- La façon la plus rapide de se conformer à PCI DSS 6.4.3 et 11.6.1
- PCI SSF ou PCI DSS : quelle norme s'applique à vous
Au 2026-06-18, considérez ceci comme une orientation opérationnelle, pas comme un avis juridique. Confirmez le libellé exact du contrôle avec votre QSA, votre conseil juridique ou votre responsable des risques.
