# La sécurité côté client de PCI DSS v4 expliquée aux responsables conformité (/fr/blog/pci-dss-v4-client-side-explained) PCI DSS v4 a ajouté deux exigences qui se jouent entièrement dans le navigateur du client : 6.4.3 et 11.6.1. Les deux sont devenues obligatoires le 31 mars 2025, et les deux restent dans le standard actuel, v4.0.1. Elles concernent les scripts et les security headers HTTP de vos pages de paiement, l'endroit où une attaque de skimming de carte vole réellement des données. Si vous êtes responsable de la conformité plutôt que du code, la question pratique est de savoir ce que ces deux exigences demandent, ce qu'un évaluateur voudra voir comme preuve, et quels contrôles la produisent. Cet article y répond en termes clairs. Pour le point de vue développeur sur la construction de la politique de sécurité du contenu qui porte tout cela, voyez [CSP et PCI DSS v4](/fr/blog/csp-pci-dss-v4). ## Pourquoi le navigateur est désormais dans le périmètre [#pourquoi-le-navigateur-est-désormais-dans-le-périmètre] Les versions plus anciennes de PCI DSS se concentraient sur vos serveurs et votre réseau. Les attaquants se sont déplacés. Un skimmer n'a plus besoin de percer votre serveur ; il modifie un script que le navigateur du client charge sur la page de checkout, et le skimmer copie les données de carte à mesure que l'acheteur les saisit. Vos logs serveur ne le voient jamais, parce que le vol se produit dans le navigateur, en route vers l'attaquant. PCI DSS v4 a donc ajouté des exigences qui pointent vers le navigateur. Les preuves correspondantes doivent venir de ce que le navigateur a vraiment chargé et exécuté, pas d'un scan de votre dépôt source ou de votre configuration serveur. Cette distinction détermine quels outils peuvent, ou non, satisfaire ces exigences. ## 6.4.3, gérer et autoriser les scripts de la page de paiement [#643-gérer-et-autoriser-les-scripts-de-la-page-de-paiement] L'exigence 6.4.3 vous demande de gérer chaque script qui se charge sur la page de paiement. En termes clairs, elle comporte trois volets : * **Inventaire.** Tenez une liste de chaque script qui s'exécute sur la page de paiement. * **Autoriser.** Gardez un enregistrement attestant que chaque script a été revu et approuvé, avec une justification écrite de sa nécessité, avant qu'il ne s'exécute. * **Garantir l'intégrité.** Disposez d'une méthode pour confirmer que chaque script autorisé n'a pas été altéré. L'intention est simple à énoncer : aucun script ne s'exécute sur votre page de paiement sans que vous l'ayez sciemment approuvé. La difficulté, en pratique, c'est que vous n'avez souvent pas la liste complète de ce qui s'y exécute, parce que les tag managers et les scripts tiers chargent d'autres scripts à l'exécution. ## 11.6.1, détecter la falsification et le changement non autorisé [#1161-détecter-la-falsification-et-le-changement-non-autorisé] L'exigence 11.6.1 vous demande de déployer un mécanisme de détection de changement et de falsification sur la page de paiement. Il doit vous alerter de toute modification non autorisée, telle que le navigateur du client la reçoit, sur deux éléments : les security headers HTTP et le contenu des scripts. Elle fixe aussi une cadence : le mécanisme évalue la page au moins une fois tous les sept jours, ou selon une fréquence que vous justifiez par votre propre analyse de risque. L'intention, là encore, s'énonce simplement : si un attaquant modifie un header ou un script sur votre page de paiement, vous l'apprenez rapidement, et depuis le point de vue du navigateur plutôt que celui de votre propre serveur. Lues ensemble : 6.4.3 consiste à connaître et approuver ce qui doit être là, 11.6.1 à être averti quand quelque chose change. ## Ce qu'un évaluateur veut voir [#ce-quun-évaluateur-veut-voir] Un évaluateur vérifie que le contrôle existe, qu'il tourne, et que vous agissez sur ce qu'il produit. Pour ces deux exigences, cela signifie généralement : * Un inventaire à jour des scripts de la page de paiement, chacun avec une justification métier enregistrée et un enregistrement d'autorisation. * La preuve de la méthode d'intégrité pour les scripts autorisés, par exemple les hashes ou la politique qui les applique. * Des enregistrements montrant que le mécanisme de détection de changement tourne à la cadence requise, et ce qu'il a trouvé. * Des enregistrements d'alertes et la réponse qui y a été apportée, montrant qu'un changement non autorisé serait détecté et traité. * Que la preuve reflète la page telle que le navigateur du client la reçoit, pas un scan côté serveur. C'est le genre de preuve qu'un évaluateur attend pour ces deux exigences. La manière dont votre outillage produit chaque pièce est à caler avec votre propre déploiement et votre évaluateur avant d'en faire état. ## Comment un inventaire de scripts et la détection de changement la fournissent [#comment-un-inventaire-de-scripts-et-la-détection-de-changement-la-fournissent] Un [inventaire de scripts](/fr/blog/script-inventory) construit à partir des rapports du navigateur liste chaque script qui s'est réellement exécuté sur la page de paiement, avec la [technologie, la version et les vulnérabilités connues](/fr/docs/platform/features/technologies) pour chacun. Associé à une justification enregistrée par script, c'est la liste inventoriée et autorisée que demande 6.4.3. La même approche attrape les scripts injectés à l'exécution que rate un scan de source, y compris les skimmers de [formjacking et Magecart](/fr/blog/magecart-formjacking-detection) qui ne se chargent que dans le navigateur. La détection de changement et l'alerte couvrent 11.6.1. Quand l'ensemble des scripts ou les headers de réponse de la page s'écartent de la ligne de base approuvée (une nouvelle origine, un script qui n'était pas là avant, un security header modifié), une alerte se déclenche. Comme le signal vient de vrais navigateurs qui chargent la page, il reflète ce que le client a reçu, exactement le point de vue que vise l'exigence. Une surveillance continue satisfait la cadence de sept jours, sans contrôle manuel hebdomadaire. Si vous utilisez un tag manager, traitez ses tags comme des scripts de page de paiement dans le périmètre. Un [tag manager peut injecter des scripts](/fr/blog/google-tag-manager-security-risk), donc chaque tag qu'il charge est à inventorier, à autoriser et à surveiller pour en détecter les changements, et un conteneur compromis est le scénario précis que 11.6.1 est censé attraper. Une vue d'ensemble de la conformité, avec la couverture de revue et les scripts en attente de décision ## Ce que « vous aide à répondre » signifie [#ce-que--vous-aide-à-répondre--signifie] CentralCSP vous donne les contrôles et les enregistrements qui satisfont l'intention de 6.4.3 et 11.6.1 : l'[inventaire de scripts](/platform/supply-chain) et la liste d'autorisation, la garantie d'intégrité, la détection de falsification via le reporting et l'alerte, et des preuves exportables pour votre évaluation. Ce qu'il ne fait pas, c'est certifier votre conformité. Un évaluateur de sécurité qualifié (QSA), ou votre propre questionnaire d'auto-évaluation quand vous y êtes éligible, prend cette décision. Nous n'écrivons jamais « certifié PCI » ni « conformité garantie », parce que cette décision n'est pas la nôtre. Le [module de preuves PCI DSS v4 reconstruit](/fr/blog/changelog) exporte ces preuves pour 6.4.3 et 11.6.1 en CSV et en PDF. Une nuance à poser clairement pour un responsable conformité : un outil qui ne scanne que votre dépôt source ou votre configuration serveur ne satisfait pas 11.6.1, parce qu'il ne voit jamais ce que le navigateur du client a reçu. Les preuves doivent venir du côté navigateur, ce qu'apporte une surveillance continue côté client. ## Prochaines étapes [#prochaines-étapes] * Lisez la vue côté développeur : [CSP et PCI DSS v4](/fr/blog/csp-pci-dss-v4). * Voyez comment un inventaire se construit : [construire un inventaire de scripts à partir des rapports CSP](/fr/blog/script-inventory). * Comprenez une menace de page de paiement dans le périmètre : [comment les attaquants abusent de Google Tag Manager](/fr/blog/google-tag-manager-security-risk). * Récupérez le standard lui-même à la source ci-dessous. [Commencez à surveiller vos pages de paiement](/register), faites pointer un header report-only de votre checkout vers CentralCSP, et regardez l'inventaire et l'historique des changements se construire à partir du trafic réel. ## Sources [#sources] * [PCI Security Standards Council, document library](https://www.pcisecuritystandards.org/document_library/) ## Articles liés [#articles-liés] * [CSP et PCI DSS v4, répondre à 6.4.3 et 11.6.1 sur les pages de paiement](/fr/blog/csp-pci-dss-v4) * [Construire un inventaire de scripts à partir des rapports CSP](/fr/blog/script-inventory) * [Comment les attaquants abusent de Google Tag Manager](/fr/blog/google-tag-manager-security-risk)