# PCI DSS 11.6.1 : détecter les changements (/fr/blog/pci-dss-11-6-1) L'[exigence 6.4.3](/fr/blog/pci-dss-6-4-3) vous fait approuver chaque script de votre page de paiement. L'exigence 11.6.1 part du principe que cette approbation ne tiendra pas éternellement. Le CDN d'un fournisseur est compromis, un compte du gestionnaire de balises se fait hameçonner, quelqu'un modifie le gabarit du checkout, et la page que reçoivent vos clients n'est plus celle que vous aviez validée. La 11.6.1 vous demande de vous en rendre compte, et d'être alerté quand cela arrive. Comme la 6.4.3, elle est obligatoire depuis le 31 mars 2025 et inchangée dans PCI DSS v4.0.1. Ce guide couvre le texte de l'exigence, les changements qui comptent, la fréquence du contrôle, la façon dont les rapports CSP et la surveillance des scripts y répondent, et ce qu'un évaluateur accepte comme preuve. ## Le texte de l'exigence [#le-texte-de-lexigence] PCI DSS v4.0.1 la formule ainsi (traduction de l'original anglais) : > Un mécanisme de détection des changements et des altérations est déployé comme suit : > > * pour alerter le personnel de toute modification non autorisée (y compris les indicateurs de compromission, changements, ajouts et suppressions) des en-têtes HTTP ayant un impact sur la sécurité et du contenu des scripts des pages de paiement, tels que reçus par le navigateur du consommateur ; > * le mécanisme est configuré pour évaluer les en-têtes HTTP et les pages de paiement reçus ; > * les fonctions du mécanisme sont exécutées au moins une fois par semaine, OU périodiquement, à une fréquence définie dans l'analyse de risque ciblée de l'entité, conformément à tous les éléments de l'exigence 12.3.1. Quatre idées s'y croisent : **détecter** une modification, **alerter** une personne, couvrir **les en-têtes comme les scripts**, et le faire **tel que le navigateur du consommateur reçoit la page**. Le [supplément d'information du PCI SSC de mars 2025](https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming) apporte un éclairage utile : la 11.6.1 admet que des changements non autorisés peuvent se produire. Elle n'exige pas de tous les empêcher. Elle exige qu'un changement soit repéré et déclenche une alerte, pour que l'on puisse corriger rapidement. Un changement non autorisé entraîne ensuite, en général, une nouvelle revue 6.4.3 du script concerné. ## Ce qui compte comme modification non autorisée [#ce-qui-compte-comme-modification-non-autorisée] Le supplément distingue trois cas, pour les en-têtes comme pour les scripts : * **Apparition** : un nouvel en-tête ou un nouveau script, par exemple une seconde directive CSP ou un nouveau fichier `.js`. * **Modification** : un en-tête ou un script existant est altéré, ou change de comportement par rapport à l'état autorisé. * **Suppression** : un en-tête comme une directive CSP, ou un script défensif, disparaît. Le troisième cas pèse plus lourd qu'il n'y paraît. Un attaquant qui veut faire tourner un skimmer sur une page protégée par une Content Security Policy (CSP) stricte n'a pas besoin de la contourner s'il peut la retirer. Un mécanisme qui ne surveille que l'apparition de scripts passe à côté. ## Quels en-têtes HTTP « ont un impact sur la sécurité » [#quels-en-têtes-http--ont-un-impact-sur-la-sécurité-] Le supplément donne des exemples et précise que la bonne liste dépend de votre architecture : Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-XSS-Protection, X-Content-Type-Options, Set-Cookie, Access-Control-Allow-Origin, Referrer-Policy, Permissions-Policy, ainsi que le trio Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy et Cross-Origin-Resource-Policy. Pour un checkout, les en-têtes qui pèsent le plus sur votre exposition sont la CSP (elle décide quels scripts peuvent tourner et où les données peuvent partir), HSTS, la protection contre l'intégration en iframe et les attributs des cookies. Commencez par ceux-là, et documentez pourquoi votre liste est celle-ci. ## Pourquoi « tel que reçu par le navigateur » change tout [#pourquoi--tel-que-reçu-par-le-navigateur--change-tout] Une analyse du dépôt de code, un contrôle d'intégrité des fichiers sur le serveur web ou une revue de la chaîne de déploiement regardent tous la page avant qu'elle n'atteigne l'acheteur. La 11.6.1 désigne l'autre bout. La page que le navigateur assemble contient des scripts récupérés directement chez les fournisseurs et les CDN, des scripts injectés à l'exécution par un gestionnaire de balises, et des en-têtes qu'un CDN ou une couche edge peut ajouter ou retirer. Rien de tout cela n'est visible depuis votre serveur d'origine. Le mécanisme doit donc regarder la page de l'extérieur, comme un navigateur : depuis les sessions réelles, depuis un navigateur synthétique qui charge la page, ou depuis un proxy placé devant. ## À quelle fréquence [#à-quelle-fréquence] Au moins une fois par semaine, ou à la fréquence fixée par une analyse de risque ciblée (TRA) au titre de l'exigence 12.3.1. Le supplément ajoute une mise en garde à retenir : des modifications malveillantes peuvent persister sans être détectées entre deux contrôles, d'où la recommandation d'une surveillance fréquente, voire en temps réel, quand c'est possible. L'hebdomadaire est un plancher, pas un objectif. Un skimmer actif six jours avant le passage du robot hebdomadaire a collecté six jours de numéros de carte. Si vous choisissez un intervalle plus long, la TRA fait partie des preuves et l'évaluateur la lira. ## Les mécanismes possibles [#les-mécanismes-possibles] Le supplément accepte un seul mécanisme ou plusieurs qui, ensemble, couvrent l'exigence. Il cite les simulations de transactions automatisées ou manuelles, les plateformes de surveillance en temps réel et les services tiers de surveillance des scripts. En termes d'outils : * **Surveillance par agent** : un script sur la page de paiement observe le DOM, les requêtes réseau et le comportement des scripts dans les sessions réelles. Inconvénient relevé par le supplément : il faut l'intégrer à chaque page, et il peut peser sur les performances. * **Surveillance sans agent** : un navigateur headless parcourt le checkout à intervalles réguliers. Il voit en-têtes et scripts, mais peut buter sur les CAPTCHA, les connexions et les parcours à état, et ne voit que ce que ses propres sessions chargent. * **Proxy** : un reverse proxy ou un CDN inspecte le HTML et les scripts à la sortie. Il voit les en-têtes et peut appliquer des politiques, au prix d'une configuration et d'une latence à maîtriser. * **CSP avec reporting** : le navigateur lui-même signale les scripts bloqués ou exécutés, depuis les sessions réelles. Le supplément reconnaît à la CSP une détection partielle des ajouts ou modifications non autorisés, et il est clair sur ses limites (voir ci-dessous). ## Ce que couvrent CSP, rapports et surveillance des scripts [#ce-que-couvrent-csp-rapports-et-surveillance-des-scripts] Le tableau 4 du supplément cite la CSP comme contrôle pour l'alerte, les changements de contenu des scripts, les indicateurs de compromission et la fréquence, mais **pas** pour les en-têtes de sécurité. C'est exact, et cela dessine une architecture réaliste : | Élément de la 11.6.1 | Ce que couvrent les rapports navigateur | Ce qu'ils ne couvrent pas | | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Un script d'une nouvelle origine apparaît | Rapport de violation CSP, depuis tous les navigateurs actuels, en session réelle | Les scripts d'une origine que votre politique autorise déjà | | Un nouveau fichier apparaît, même depuis une origine autorisée | Rapport `csp-hash` avec `'report-sha256'` : chaque script exécuté, par URL | Firefox n'envoie pas encore de rapports de hash | | Le contenu d'un script approuvé change | Un SHA-256 différent pour la même URL dans les rapports `csp-hash` | Un script cross-origin servi sans CORS n'a pas de hash exploitable | | Un script disparaît | Ses rapports cessent d'arriver | Signal faible : vérifiez dans l'inventaire les scripts qui ne sont plus vus | | Un en-tête de sécurité change ou disparaît | Non couvert par les rapports CSP | Il faut un contrôle des en-têtes : synthétique, proxy ou requête planifiée | | Alerte | Un collecteur qui compare les rapports à votre référence approuvée et prévient une personne | La CSP envoie des rapports, pas des alertes | En résumé : les rapports navigateur couvrent bien la moitié « scripts » de la 11.6.1, en continu et depuis les sessions réelles. La moitié « en-têtes » demande un mécanisme qui lit les en-têtes de réponse. Un contrôle minimal peut se résumer à une tâche planifiée qui récupère la page de paiement et compare les en-têtes qui vous intéressent à une référence enregistrée : ```bash curl -sI https://shop.example.com/checkout \ | grep -iE '^(content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy|permissions-policy):' \ | tr -d '\r' | sort > headers-today.txt diff headers-baseline.txt headers-today.txt || notify-security-team ``` Lancez-le au moins chaque semaine (chaque jour ne coûte rien), alertez sur toute différence et conservez le résultat. Les attributs de cookies demandent une comparaison à part, car les valeurs de `Set-Cookie` changent à chaque requête. Une CSP à nonce change elle aussi à chaque réponse : retirez la valeur du nonce avant de comparer. Le [scanner d'en-têtes de sécurité](/tools/security-headers) gratuit montre ce qu'une page envoie aujourd'hui, pratique pour établir la référence. ## Alerte et réponse [#alerte-et-réponse] La 11.6.1 dit « alerter le personnel ». Une ligne dans un tableau de bord que personne n'ouvre n'est pas une alerte. Le supplément cite l'e-mail, le SMS, les événements SYSLOG, le journal de sécurité Windows ou les journaux d'un outil éditeur. Les canaux de chat et les webhooks vers votre outil de ticketing ou d'astreinte en sont les équivalents actuels. L'alerte doit aussi déboucher sur une action. L'exigence 12.10.5 impose que votre plan de réponse aux incidents couvre la surveillance et le traitement des alertes du mécanisme de détection des pages de paiement. L'évaluateur peut demander à observer le processus, ou un exercice sur table s'il n'y a pas eu d'incident réel. Décidez à l'avance ce qui se passe quand une alerte tombe : qui la regarde et sous quel délai, comment distinguer une mise à jour prévue d'un fournisseur d'une compromission, et qui peut retirer un script du checkout. ## Ce qui compte comme preuve [#ce-qui-compte-comme-preuve] Le tableau 9 du supplément liste ce qu'un évaluateur attend pour la 11.6.1 : * **Les réglages** du mécanisme de détection. * **La liste des pages de paiement surveillées.** * **Les résultats de la surveillance** : journaux, rapports ou autres sorties. * **Une configuration montrant que le mécanisme détecte et alerte** sur les modifications non autorisées des en-têtes et des scripts, et évalue les en-têtes et pages reçus. * **La TRA documentée**, si vous contrôlez moins souvent qu'une fois par semaine. * **Une configuration et des entretiens** confirmant la fréquence. Ajoutez les rôles et responsabilités liés à la 11.6.1 (exigence 11.1.2) et l'entrée correspondante du plan de réponse aux incidents (12.10.5). Le supplément note aussi que l'inventaire de la 6.4.3 peut servir à configurer le mécanisme, et c'est ainsi que la plupart des équipes relient les deux exigences : l'inventaire sert de référence, et la 11.6.1 alerte sur tout écart. Conseil pratique : gardez quelques alertes réelles et la trace de leur traitement. Un historique d'alertes avec leur issue vaut mieux qu'une capture d'écran de configuration. ## La place de CentralCSP [#la-place-de-centralcsp] CentralCSP couvre la partie « scripts » de la 11.6.1 à partir du trafic réel des navigateurs, sans rien ajouter au checkout. Il collecte les rapports de violation et de hash CSP de vos pages de paiement et les compare à l'inventaire approuvé construit pour la 6.4.3. Des règles d'alerte préviennent ensuite Slack, Microsoft Teams, Google Chat, Telegram, l'e-mail ou un webhook quand : * un script apparaît sur une page de paiement sans que personne l'ait justifié (**New unjustified script**) ; * un script d'une page de paiement sert un contenu que personne n'a justifié, y compris un script approuvé avec son hash précédent (**Unjustified script change**), la notification indiquant le hash revu et le hash servi ; * une origine de script est vue pour la première fois (**New script origin**). Chaque détection, changement de hash et décision est consigné dans un journal en ajout seul, et l'[export des preuves](/fr/docs/platform/features/pci-dss/evidence-export) remet à l'évaluateur un rapport PDF et des CSV complets de l'inventaire et du journal des changements. Les données sont hébergées en France, chez OVH. Deux limites. Les rapports de hash ne viennent que des navigateurs Chromium et de Safari, pas de Firefox : l'inventaire des scripts reflète ce trafic, tandis que les rapports de violation viennent de tous les navigateurs actuels. Et les alertes PCI de CentralCSP ne comparent pas les en-têtes de réponse HTTP : associez-le à un contrôle des en-têtes comme celui ci-dessus. CentralCSP vous aide à répondre à la 11.6.1 ; c'est votre QSA qui juge si les preuves suffisent. Voir la [page PCI DSS](/platform/pci-dss) et la documentation des [règles d'alerte](/fr/docs/platform/features/alerting/rules). ## Questions fréquentes [#questions-fréquentes] ### Un robot hebdomadaire suffit-il pour la 11.6.1 ? [#un-robot-hebdomadaire-suffit-il-pour-la-1161-] Il respecte la fréquence minimale, mais un skimmer peut tourner plusieurs jours entre deux passages, et un robot ne voit que ce que ses propres sessions chargent. Le PCI SSC recommande une surveillance fréquente, voire en temps réel, quand c'est possible. ### Une CSP suffit-elle pour la 11.6.1 ? [#une-csp-suffit-elle-pour-la-1161-] Non. Les rapports CSP aident à détecter les scripts non autorisés et les changements de scripts, mais une CSP n'alerte personne par elle-même, ne garde aucune référence, et ne peut pas détecter qu'un en-tête de sécurité a été modifié ou retiré. Il faut un collecteur qui transforme les rapports en alertes, plus un contrôle des en-têtes. ### La 11.6.1 s'applique-t-elle aux marchands SAQ A ? [#la-1161-sapplique-t-elle-aux-marchands-saq-a-] Le SAQ A ne la liste plus depuis janvier 2025. Si votre page intègre le formulaire de paiement d'un prestataire, le critère d'éligibilité du SAQ A vous demande de confirmer que le site n'est pas exposé aux attaques par script. La FAQ 1588 du PCI SSC indique que vous pouvez le faire en appliquant des techniques comme celles de 6.4.3 et 11.6.1, ou avec une confirmation écrite de votre prestataire. Voir [le guide de la 6.4.3](/fr/blog/pci-dss-6-4-3#le-saq-a-depuis-janvier-2025). ### La 11.6.1 concerne-t-elle la page qui intègre une iframe de paiement ? [#la-1161-concerne-t-elle-la-page-qui-intègre-une-iframe-de-paiement-] Oui. Le supplément du PCI SSC place la page parente qui intègre une iframe de paiement dans le périmètre de 6.4.3 et 11.6.1. Une page qui se contente de rediriger vers la page hébergée du prestataire n'est pas concernée. ## Sources [#sources] * [PCI SSC, Payment Page Security and Preventing E-Skimming, Guidance for PCI DSS Requirements 6.4.3 and 11.6.1 (mars 2025), annonce](https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming) * [PCI SSC, FAQ 1588](https://www.pcisecuritystandards.org/faqs/1588) * [PCI SSC, bibliothèque documentaire (PCI DSS v4.0.1)](https://www.pcisecuritystandards.org/document_library/) * [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/) * [W3C, Reporting API](https://www.w3.org/TR/reporting-1/) * [WebKit, WebKit features in Safari 18.4 (Security)](https://webkit.org/blog/16574/webkit-features-in-safari-18-4/) ## Articles liés [#articles-liés] * [PCI DSS 6.4.3 : gérer les scripts de paiement](/fr/blog/pci-dss-6-4-3) * [Scripts de paiement et PCI DSS : les questions que se posent les équipes](/fr/blog/pci-payment-page-scripts-faq) * [Outils PCI DSS 6.4.3 et 11.6.1 comparés](/fr/blog/pci-dss-script-inventory-tools) * [Détecter un skimmer Magecart](/fr/blog/magecart-formjacking-detection)