# 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 vivent 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 la vue côté développeur sur la construction de la politique de sécurité du contenu qui soutient 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 les données de carte sont copiées à 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 pour elles doivent venir de ce que le navigateur a réellement chargé et exécuté, pas d'un scan de votre dépôt source ou de votre configuration serveur. Cette distinction décide quels outils peuvent satisfaire ces exigences tout court. ## 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 a trois parties : * **Inventaire.** Tenez une liste de chaque script qui s'exécute sur la page de paiement. * **Autoriser.** Ayez 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é.** Ayez 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 est que vous n'avez souvent pas de 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 de deux choses telles que reçues par le navigateur du client : 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 porte sur le fait de connaître et d'approuver ce qui doit être là, et 11.6.1 porte sur le fait d'ê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 façon dont votre outillage spécifique produit chaque pièce est quelque chose à caler avec votre propre déploiement et votre évaluateur avant de la citer. ## 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 derrière 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 qu'un scan de source manque, 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 diffèrent de la ligne de base approuvée, une nouvelle origine, un script qui n'était pas là avant, ou un security header modifié, une alerte se déclenche. Parce que le signal vient de vrais navigateurs chargeant la page, il reflète ce que le client a reçu, ce qui est exactement le point de vue que l'exigence nomme. La cadence de sept jours est satisfaite par une surveillance continue plutôt que par un 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 quelque chose que vous devez inventorier, autoriser et surveiller pour changement, 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. 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 que fournit une surveillance côté client continue. ## 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), pointez un header report-only depuis votre checkout vers lui, 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)