Dans ce blog :
- Ce que les auditeurs vérifient pour PCI 6.4.3 et 11.6.1
- Exemples d'attaques et d'amendes
- Comparaison des solutions éditeurs
- Ressources pour votre équipe (checklists, évaluations)
Les exigences PCI 6.4.3 et 11.6.1 portent sur un seul sujet : le contrôle et la visibilité sur ce qui s'exécute dans le navigateur de vos utilisateurs. Plus précisément sur les pages de paiement. Ces exigences obligent les entreprises à enfin comprendre ce qui se passe côté client : quels scripts se chargent ? Ont-ils été approuvés ? Leur comportement est-il suspect ? Étonnamment, la plupart des équipes n'ont pas les réponses à ces questions. Elles n'en ont jamais vraiment eu besoin. Et maintenant, ces équipes s'empressent de se conformer aux audits PCI DSS 4.0.1. Selon le rapport 2024 de Verizon sur la sécurité des paiements, le pourcentage d'organisations maintenant une conformité totale a régulièrement diminué, tombant à 33 % en 2023.
Nous avons travaillé avec de nombreux responsables sécurité dans l'eCommerce, le Retail et la FinTech pour mettre en œuvre des solutions conformes à la norme PCI sur des pages traitant des données utilisateurs sensibles (comme les cartes de paiement). Après avoir observé les erreurs courantes et les bonnes pratiques, nous avons compilé un guide issu de notre expérience pour faciliter votre processus de mise en conformité.
« Les étapes techniques pour atteindre la conformité PCI 6.4.3 & 11.6.1 sont quelque chose qu'on me demande régulièrement d'expliquer aux équipes conformité. Les documents sont clairs sur ce qui est requis, mais la manière de mettre en œuvre les mécanismes reste une zone grise que les équipes sécurité doivent déchiffrer par elles-mêmes. »
— Simon Wijckmans, Fondateur, cside
Quelles sont les exigences PCI DSS 6.4.3 ?
Dans le cadre des ajouts PCI DSS 4.0.1 devenus obligatoires le 31 mars 2025, l'exigence 6.4.3 impose aux entreprises de :
- Tenir un inventaire de chaque script s'exécutant sur les pages de paiement.
- Documenter la raison pour laquelle chaque script est nécessaire (justification métier).
- Vérifier l'intégrité de chaque script (s'assurer qu'il n'a pas été altéré).
- Détecter et alerter en cas de modifications non autorisées de scripts.
Ce que cela signifie concrètement : Sur les pages qui traitent des informations utilisateurs sensibles (cartes de paiement, informations de santé, données personnelles), vous devez disposer d'un mécanisme permettant de surveiller les scripts tiers, ce qu'ils font dans les navigateurs de vos utilisateurs, et d'alerter les équipes sécurité lorsque des scripts ont un comportement suspect.
*Définitions basées sur PCI DSS v4.0.1 - juin 2024. Il s'agit de la version la plus récente à la date de septembre 2025. Pour consulter les documents officiels, rendez-vous sur la bibliothèque PCI SSC.
Quelles sont les exigences PCI DSS 11.6.1 ?
Dans le cadre des ajouts PCI DSS 4.0.1 devenus obligatoires le 31 mars 2025, l'exigence 11.6.1 impose aux entreprises de :
- Alerter le personnel en cas de modifications non autorisées des en-têtes HTTP et des scripts des pages de paiement
- Évaluer les en-têtes HTTP reçus et les pages de paiement
- Opérer au moins chaque semaine ou selon l'analyse de risque de l'entité (Exigence 12.3.1)
Ce que cela signifie concrètement : Les en-têtes HTTP sont des règles qui indiquent au navigateur d'un utilisateur comment traiter le contenu d'une page. La modification de ces en-têtes (par exemple par un script malveillant) peut affaiblir les protections de sécurité. La norme PCI DSS 11.6.1 exige que les entreprises disposent d'un mécanisme qui vérifie régulièrement (au moins une fois tous les sept jours) les modifications non autorisées des en-têtes et alerte l'équipe sécurité lorsqu'elles se produisent.
Méthodes pour atteindre la conformité 6.4.3 et 11.6.1 (acheter ou construire soi-même) :
- Construire une solution en interne : Créer des outils internes pour scraper les pages de paiement, journaliser les scripts, analyser leurs charges utiles et alerter en cas de modifications. Cette approche nécessite un investissement continu en temps d'ingénierie de la part de personnel spécialisé.
- Utiliser un outil prêt à l'emploi : Une plateforme d'intelligence côté client maintiendra automatiquement un inventaire de scripts en temps réel, fournira des justifications et enverra des alertes en cas de modifications non autorisées. Les fonctionnalités de reporting sont souvent conçues spécifiquement pour les audits PCI DSS.
« Sur la question de construire en interne ou d'acheter un outil : c'est une décision propre à chaque entreprise. Mais je n'ai encore jamais eu de client qui l'ait fait correctement en interne. Dans toute notre entreprise, je n'ai vu qu'un seul client y parvenir. Et cela après avoir travaillé avec des centaines de clients. Un outil éditeur élimine vraiment les approximations. »
- Marc Jackson, QSA & Conseiller en conformité, MegaplanIT
Décryptage de la norme PCI DSS 6.4.3 et étapes de mise en conformité
Qui est responsable de la conformité 6.4.3 et 11.6.1 :
- Les développeurs contrôlent les scripts déployés et maintiennent l'inventaire à jour.
- Les équipes sécurité surveillent les modifications suspectes et traitent les alertes.
- Les équipes conformité s'assurent que la documentation, les approbations et les pistes d'audit répondent aux normes PCI.
À quoi ressemble un reporting approuvé par un QSA pour les exigences 6.4.3 et 11.6.1 :
Certains outils peu coûteux ou gratuits exportent des tableaux de bord désordonnés ou des fichiers CSV. Ces formats sont difficiles à interpréter pour les auditeurs et encore plus difficiles à opérationnaliser pour les équipes internes. En pratique, les QSA recherchent des rapports structurés et consultables qui présentent l'inventaire des scripts, le statut d'autorisation et la détection des modifications dans le temps. Un reporting clair facilite également la réaction rapide de votre équipe face à un comportement suspect.
Cette vidéo présente les rapports que nous utilisons à la fois en tant qu'entreprise SAQ-D auditée de manière indépendante et en tant qu'éditeur dont les contrôles ont été validés par VikingCloud.
<a
class="pci-video-card__cta"
href="https://cside.com/landing/pci-demo-video"
target="_blank"
rel="noopener noreferrer"
>
<span class="pci-video-card__icon" aria-hidden="true">
<svg viewBox="0 0 48 48" fill="none" xmlns="http://www.w3.org/2000/svg">
<circle cx="24" cy="24" r="20.5" stroke="currentColor" stroke-width="2"/>
<path d="M20 16.5L31 24L20 31.5V16.5Z" stroke="currentColor" stroke-width="2" stroke-linejoin="round"/>
</svg>
</span>
<span>Regarder la vidéo</span>
</a>
Ce que les auditeurs vérifient pour la conformité PCI 6.4.3
1. Tenir un inventaire de chaque script s'exécutant sur les pages de paiement
« J'utilise tellement de scripts tiers : outils d'analyse, widgets de support, polyfills, bibliothèques d'animation, CDN. N'importe lequel d'entre eux pourrait devenir malveillant et remplacer le contenu légitime par un enregistreur de frappe ou pire. » - Edgardo C., Développeur (Citation extraite d'un avis cside)
La plupart des sites web ont entre 5 et plus de 100 scripts. Une plateforme d'intelligence côté client tient un inventaire sur toutes les pages (y compris les pages de paiement de votre domaine) et vous montre la charge utile du script à chaque requête. Cela vous permet de voir les modifications de code, les mises à jour et les actions potentiellement malveillantes. Ces informations sont organisées clairement dans un tableau de bord pour offrir une visibilité aux parties prenantes. Bien que non exigé par la norme PCI DSS 4.0.1, certaines plateformes bloquent également les modifications (malveillantes) et vous en alertent.
2. Documenter la raison pour laquelle chaque script est nécessaire avec une justification métier (PCI 6.4.3)
Répondre manuellement à cette exigence suit généralement ce processus :
-
- Exporter une liste de scripts depuis un crawler web ou un outil navigateur, 2. Identifier le propriétaire de chaque script (interne, fournisseur), 3. Tout consigner dans un document central (par exemple un tableur), 4. Ajouter un champ texte avec une justification expliquant pourquoi le script est nécessaire, 5. Mettre à jour le document chaque fois que des scripts sont ajoutés, supprimés ou modifiés.
Une plateforme d'intelligence côté client :
- Stocke chaque justification directement aux côtés du script dans votre inventaire, garantissant que le contexte est toujours à jour en un emplacement central.
- Génère des justifications assistées par IA pour chaque script. Cela donne aux équipes un point de départ pré-rédigé qu'elles peuvent examiner, approuver ou ajuster.
3. Vérifier l'intégrité de chaque script pour s'assurer qu'il n'a pas été altéré (PCI 6.4.3)
Des acteurs malveillants peuvent modifier des scripts pour les faire se comporter d'une manière non prévue à l'origine. Par exemple :
- Modifier des formulaires de paiement pour envoyer des données vers un serveur contrôlé par un attaquant (exfiltration de données)
- Ajouter des champs de saisie cachés ou des enregistreurs de frappe pour collecter les identifiants des titulaires de carte
C'est pourquoi les solutions multicouches qui analysent le JavaScript lors de chaque session en direct sont essentielles. Elles voient chaque script exactement tel qu'il est exécuté dans le navigateur de l'utilisateur. Cela permet aux ingénieurs de comprendre facilement ce que fait le script. L'IA filtre également les modifications et donne un aperçu de ce que la fonctionnalité ajoutée ou modifiée pourrait faire.
4. Détecter et alerter en cas de modifications non autorisées de scripts (PCI 6.4.3)
Vous devez montrer aux auditeurs comment les scripts ont évolué dans le temps. Une technique d'attaque courante consiste à apporter de petites modifications à des scripts existants. Ces modifications passent fréquemment inaperçues car les équipes sécurité ne peuvent pas (et ne peuvent réalistement pas) examiner manuellement les modifications de code de chaque script en continu. Un outil de surveillance automatisé suivra ces modifications et enregistrera les horodatages pour vous fournir un historique clair à consulter.
Décryptage de la norme PCI DSS 11.6.1 et étapes de mise en conformité
L'exigence 11.6.1 est un peu plus technique. Elle stipule que le personnel doit être alerté lorsque les en-têtes HTTP et les scripts des pages de paiement changent. Il est pratiquement impossible de le faire manuellement. Le JavaScript tiers n'est pas conçu pour rester statique. Il se met à jour en fonction de la localisation de l'utilisateur, du type de navigateur et de l'heure de la journée. Certains scripts doivent servir différentes versions pour des raisons fonctionnelles. Alors comment peut-on voir, et encore moins comprendre, ces modifications ?
Ce que les auditeurs vérifient pour la conformité PCI 11.6.1
1. Alerter le personnel en cas de modifications non autorisées des en-têtes HTTP et des scripts des pages de paiement (PCI 11.6.1)
Les en-têtes HTTP sont des règles qui indiquent au navigateur d'un utilisateur comment traiter le contenu d'une page. Si ceux-ci sont modifiés, cela représente un risque de sécurité. Une solution de sécurité web côté client surveille les données des scripts pour détecter les différences de comportement entre des sessions distinctes.
2. Évaluer les en-têtes HTTP reçus et les pages de paiement (PCI 11.6.1)
Évaluer les en-têtes HTTP signifie surveiller des éléments comme les politiques de sécurité du contenu. Le faire manuellement page par page conduira inévitablement à des signaux manqués. Un outil de sécurité côté client le fait automatiquement, de sorte que chaque en-tête est validé et que le processus d'évaluation est moins contraignant pour votre équipe.
3. Opérer au moins chaque semaine ou selon l'analyse de risque de l'entité (PCI 11.6.1 et 12.3.1)
La norme PCI DSS vous offre deux options ici. Effectuez vos vérifications au moins une fois par semaine. Ou effectuez-les plus souvent si votre propre analyse de risque l'indique. Lorsque cela est fait manuellement, il faudrait que quelqu'un charge la page de paiement, récupère les en-têtes HTTP, les compare à la copie de la semaine précédente, et fasse de même pour le contenu de la page. Puis tout documenter chaque semaine, ou plus souvent si votre profil de risque l'exige.
cside enregistre les en-têtes à chaque chargement de votre page, vous évitant ainsi les comparaisons manuelles. Des rapports sont envoyés régulièrement dans votre boîte de réception (par exemple chaque semaine) et stockés dans la plateforme. Cela crée une piste documentaire complète pour la conformité.
Pourquoi la conformité PCI est importante (exemples d'attaques et d'amendes)
La norme PCI DSS existe pour protéger les internautes contre le vol de leurs informations de paiement. Plus de 72 000 sites web ont été compromis au seul deuxième trimestre 2025. Si des pirates informatiques parviennent à modifier le code chargé dans un navigateur, ils peuvent voler bien plus que des informations de carte de crédit. Ils volent des identités. Ils vident des comptes bancaires. Ils laissent les victimes face à un désordre qui peut prendre des mois à régler. Le respect des règles PCI vous aide à éviter des amendes allant de 5 000 à 100 000 dollars. Il vous protège également contre les fuites de données côté client qui coûtent aux entreprises plus de 20 millions de dollars, sans compter la perte de confiance précieuse des consommateurs.
Comparaison des outils pour PCI 6.4.3 et 11.6.1
De nombreuses solutions PCI visent à cocher la case de conformité sans offrir une protection réelle à vos utilisateurs. D'autres solutions utilisent des technologies obsolètes, laissant les clients surpris lorsqu'ils ne passent pas les audits PCI après une implémentation de plusieurs mois. Assurez-vous que la solution de votre éditeur a été examinée et approuvée par un QSA (Qualified Security Assessor) accrédité.
Différentes approches techniques pour PCI 6.4.3 et 11.6.1
L'analyse suivante est tirée de la Comparaison des technologies de sécurité côté client :
Les approches basées sur des crawlers analysent la page après coup, et souvent seulement de manière périodique. Elles ne parviennent pas à reproduire le comportement réel des utilisateurs et les attaquants peuvent facilement échapper à la détection en servant des scripts propres aux crawlers tout en ciblant les utilisateurs réels avec des charges utiles malveillantes.
Les politiques de sécurité du contenu (CSP) ont une portée limitée. Elles traitent la source du script plutôt que sa charge utile. Lorsque la source est compromise, cela passe inaperçu. Lorsqu'un script dynamique est utilisé, une politique de sécurité du contenu n'a aucun moyen de savoir ce que ce script sert réellement.
La détection JavaScript côté client (également appelée Agents) injecte des scripts de surveillance dans les navigateurs. Ces scripts mettent en place des pièges pour tenter de détecter le JavaScript malveillant. Seulement, ces pièges sont généralement faciles à trouver et donc à contourner.
cside répond à tous les problèmes mentionnés ci-dessus en utilisant une solution multicouche qui inclut des agents JS, des scanners, des CSP, des flux de renseignements sur les menaces, et bien plus encore. La plateforme cside récupère également les scripts vers ses propres serveurs de manière asynchrone pour une inspection complète sans introduire de friction dans les parcours utilisateurs.
Outils populaires pour PCI 6.4.3 et 11.6.1
| Nom | Approche | Avis | En savoir plus |
|---|---|---|---|
| cside | Approche multicouche avec agent JavaScript | ★★★★★ (4,9 étoiles) sur G2 | Évaluation de la solution cside |
| Feroot | Détection basée sur JavaScript | ★★★★★ (4,8 étoiles) sur G2 | Évaluation de la solution Feroot |
| Imperva | Politique de sécurité du contenu (CSP) | ★★★★☆ (4,5 étoiles) sur G2 | Évaluation de la solution Imperva |
| DataDome | Agent JavaScript | ★★★★★ (4,8 étoiles) sur G2 | Évaluation de la solution DataDome |
| JScrambler | Agent JavaScript | ★★★★☆ (4,3 étoiles) sur G2 | Évaluation de la solution JScrambler |
« Les capacités de détection que nous avons obtenues avec cside étaient sans commune mesure avec ce que nous avions vu dans d'autres produits testés par le passé. Nous recommanderions sans hésiter ce produit pour la conformité PCI et au-delà. » - Mark D., (Avis G2 sur cside)
L'intégrité des sous-ressources (SRI) pour la conformité PCI DSS
Dans le document PCI DSS v4.0.1, le PCI SSC liste la SRI (intégrité des sous-ressources) comme mécanisme valide pour vérifier l'intégrité des scripts et satisfaire à l'exigence 6.4.3. Vous pouvez en savoir plus sur l'intégrité des sous-ressources ici pour comprendre son fonctionnement.
Pourquoi la SRI seule ne suffit pas pour la norme PCI DSS 6.4.3 en pratique
L'intégrité des sous-ressources fonctionne bien pour les scripts statiques, mais elle montre ses limites face aux scripts dynamiques. De nombreux scripts web tiers sont dynamiques et fréquemment mis à jour. Chaque modification légitime nécessite un nouveau hachage et un redéploiement, ce qui devient rapidement ingérable. Si votre site dispose d'une équipe marketing, vous avez probablement des scripts dynamiques — pensez aux balises d'analyse, aux outils de test A/B ou aux pixels de suivi.
La SRI n'est donc pas une méthode de conformité PCI DSS ou de sécurité viable pour un environnement web avec des scripts dynamiques.
Combiner la SRI avec une directive CSP (script-src) renforce la protection, mais cette approche échoue également lorsque les scripts se mettent à jour fréquemment. Toute modification légitime du contenu invalide le hachage, ce qui empêche le chargement du script et peut casser des fonctionnalités sur votre site.
Alternative à la SRI pour vérifier l'intégrité des scripts :
Plutôt que de s'appuyer sur la maintenance manuelle des CSP et de la SRI pour la conformité PCI DSS, vous pouvez déployer un outil de surveillance de l'intégrité des scripts. Les solutions modernes comme cside analysent en continu les modifications suspectes et alertent sur les changements en se basant sur une variété de points de données :
- Analyse IA continue : évalue le comportement des scripts dans le navigateur pour signaler les anomalies ou le code injecté
- Comparaison historique des hachages : suit les modifications entre les versions précédentes des scripts pour une analyse forensique précise des altérations ou des mises à jour
- Renseignements sur les menaces : croise les scripts avec les expositions connues de la chaîne d'approvisionnement web qui affectent les scripts de votre site.
Obtenez l'aide de notre équipe
Besoin de clarté sur les exigences PCI 6.4.3 ou 11.6.1 ? Notre équipe peut évaluer les angles morts de votre infrastructure actuelle et vous montrer comment cside facilite la mise en conformité.
cside vous donne tout ce dont vous avez besoin pour réussir les audits PCI 6.4.3 et 11.6.1.
✓ Inventoriez automatiquement chaque script sur vos pages de paiement et suivez les modifications en temps réel.
✓ Stockez les justifications et gagnez des heures grâce aux justifications générées par IA que vous pouvez approuver ou modifier.
✓ Surveillez les en-têtes HTTP et détectez les modifications non autorisées, en alertant instantanément votre équipe.
Checklist synthétique pour PCI DSS 6.4.3 et 11.6.1
Pour les exigences 6.4.3 et 11.6.1, voici la checklist synthétique que nous parcourons lors de notre premier échange avec les équipes sécurité :
| ◯ | Disposez-vous d'un mécanisme capable de détecter les scripts malveillants ? |
| ◯ | Disposez-vous d'un mécanisme qui bloque les scripts malveillants (et pouvez-vous prouver qu'il a réellement vérifié le code) ? |
| ◯ | Tenez-vous une liste des scripts avec des justifications métier et techniques ? |
| ◯ | Surveillez-vous les en-têtes HTTP sur une page web ? |
| ◯ | Comprenez-vous les différentes approches techniques pour la sécurité côté client ? (CSP, agent JS, proxy) ? |
| ◯ | Prévoyez-vous de vous conformer aux nouvelles exigences avec une solution développée en interne ou avec des outils prêts à l'emploi ? |
FAQ sur PCI DSS 6.4.3 et 11.6.1
Êtes-vous exempté de vous conformer aux exigences PCI 6.4.3 et 11.6.1 ? (Auto-évaluation pour SAQ A)
La mise à jour de janvier 2025 du SAQ A par le PCI DSS a introduit des exemptions possibles pour les exigences 6.4.3 et 11.6.1, mais les critères sont formulés en termes vagues et généraux. En pratique, vous devriez prouver que vos pages de paiement ne contiennent aucun script tiers ni autre contenu dynamique. Ce scénario est rare pour la plupart des commerçants. L'exemption est extrêmement difficile à obtenir. Pour un examen détaillé des critères et un schéma logique visuel que vous pouvez utiliser pour évaluer votre propre situation, consultez notre article dédié « Qu'est-ce qu'un SAQ A et comment l'appliquer ».
Comment se conformer gratuitement à la norme PCI DSS 6.4.3
Il n'existe pas d'outils éditeurs qui vous rendent pleinement conforme à la norme PCI gratuitement. Certains proposent un essai gratuit ou un niveau gratuit limité, mais avec un trafic web significatif, vous paierez des coûts à l'usage. L'autre option consiste à construire une solution maison en interne. Même si vous disposez des compétences techniques nécessaires, cela finit par coûter bien plus cher que l'achat d'une solution prête à l'emploi. Si vous souhaitez le détail technique de ce qu'implique une approche DIY, consultez notre article : Atteindre la conformité PCI sans acheter de solution.
