PCI DSS 6.4.3 demande trois choses sur chaque page de paiement : un inventaire de chaque script, une confirmation que chacun est autorisé, et l'assurance que l'intégrité de chaque script tient. L'inventaire et le registre d'autorisation sont là où la plupart des équipes calent. Ce post ne traite que ces deux artefacts — comment les construire, quels champs chaque registre porte, et comment empêcher qu'ils dérivent la semaine qui suit l'audit.
Le contrôle est devenu obligatoire le 2025-03-31. Un instantané de tableur pris une fois puis oublié ne le satisfait pas, parce que la chose contrôlée — le JavaScript tiers — change selon son propre calendrier. Un inventaire propre est un registre vivant avec un owner, une justification et un historique de versions par script. Obtenez d'abord la bonne structure de registre ; la décision d'outil en découle.
Pour le libellé exact de l'exigence, le débat acheter-vs-construire, et ce que les auditeurs regardent de bout en bout, lisez le guide pratique PCI 6.4.3 et 11.6.1 et le guide d'évaluation QSA. Cette page reste étroite sur la mécanique de l'inventaire.
Quel périmètre l'inventaire doit-il couvrir ?
Le PCI SSC borne 6.4.3 aux scripts chargés et exécutés dans le navigateur du consommateur sur la page de paiement — aussi bien les scripts issus de l'environnement propre de l'entité que les scripts chargés depuis des tierces et quatrièmes parties. Lisez ce périmètre au pied de la lettre avant de commencer à lister. Votre inventaire doit capturer :
- Scripts first-party / same-origin — vos propres bundles, servis depuis votre domaine.
- Scripts inline — snippets collés dans le template HTML, y compris les bootstraps de tag managers.
- Scripts tiers — analytics, tests A/B, widgets de support, SDKs de fraude, helpers de paiement.
- Scripts de quatrième partie — tout ce qu'un script tiers charge après s'être exécuté. Ceux-ci n'apparaissent jamais dans un contrat vendor ni dans un tag manager.
La couche de quatrième partie est celle que les équipes oublient. Un seul tag analytics peut tirer une chaîne de scripts supplémentaires au runtime que personne n'a approuvés directement. Si votre inventaire part d'une liste de vendors ou d'un export de tag manager, cette chaîne est invisible. Partez de ce que le navigateur reçoit réellement sur la page de paiement en production.
Quels champs chaque ligne d'inventaire doit-elle porter ?
Une ligne d'inventaire est une preuve. Elle doit répondre à « qu'est-ce que c'est, d'où ça vient, et est-ce la même chose que la semaine dernière » sans que personne n'ouvre devtools en plein audit. Les colonnes minimales utiles :
| Champ | Ce qu'il enregistre | Pourquoi un QSA le veut |
|---|---|---|
| URL / source du script | URL complète, ou inline pour le code embarqué | Identifie l'asset et son domaine d'origine |
| Niveau de partie | Première, tierce ou quatrième partie | Prouve que les chaînes de quatrième partie sont comptabilisées |
| Hash de contenu | Hash du payload réellement servi | Ancre les checks d'intégrité sur le contenu réel, pas un nom de fichier |
| First seen / last seen | Quand il est apparu, quand observé pour la dernière fois | Signale les scripts disparus ou apparus sans enregistrement de changement |
| Owner | Personne responsable nommée | Trace qui peut justifier le script |
| Justification business | Pourquoi il tourne près de la page de paiement | Satisfait la clause de « justification écrite » |
| Note d'accès aux données | Ce que le script peut lire sur la page | Fait émerger tout ce qui touche aux champs de formulaire |
| Statut d'autorisation | Autorisé / pending / rejeté | La confirmation d'autorisation 6.4.3 elle-même |
| Historique de versions | Hashes antérieurs avec timestamps | Montre que le registre est maintenu, pas un instantané |
Les deux colonnes qui séparent une vraie preuve d'une case à cocher sont hash de contenu et historique de versions. Une ligne qui ne liste qu'une URL prouve que le script existe. Une ligne qui épingle le hash du payload servi au navigateur, et conserve les hashes antérieurs, prouve que vous savez dire quand ce script a changé — ce qui est le pont entre l'inventaire de 6.4.3 et la détection de changements de 11.6.1.
À quoi ressemble un registre d'autorisation unique ?
L'autorisation n'est pas une case que l'on coche. C'est une décision que quelqu'un a prise et peut défendre. Un registre complet lie le script à une personne, une raison et un moment. Voici une ligne remplie comme exemple travaillé :
| Champ | Valeur |
|---|---|
| Source du script | https://cdn.example-analytics.com/v3/tag.js |
| Niveau de partie | Tiers |
| Hash de contenu | sha256:8f2a…c91d (payload servi 2026-06-15) |
| Owner | Priya N., Web Platform Lead |
| Justification business | Analytics de funnel pour le reporting de conversion au checkout |
| Note d'accès aux données | Lit l'URL de page et les événements de clic ; pas d'accès aux champs de carte |
| Statut d'autorisation | Autorisé — approuvé 2026-06-15 |
| Historique de versions | sha256:8f2a…c91d (2026-06-15), sha256:4b07…aa12 (2026-05-02) |
Notez la note d'accès aux données. Elle ne dit pas seulement que le script est autorisé — elle indique ce que le script est autorisé à toucher. Quand la prochaine version de ce tag commence soudainement à lire le champ de carte, l'écart entre la note et le comportement observé est l'alerte. Une justification sans limite énoncée ne peut pas être violée, donc elle ne peut jamais rien déclencher.
Comment empêcher l'inventaire de devenir périmé ?
Le mode de défaillance est prévisible. Une équipe construit un inventaire exhaustif pour l'audit, passe, et en quelques semaines le marketing pousse un nouveau tag, un vendor pousse une v3 de son SDK, et une dépendance de quatrième partie change de domaine. Rien de tout ça n'atterrit dans le tableur. L'inventaire est désormais de la fiction, et la prochaine évaluation l'expose.
Un inventaire maintenable suit une boucle, pas une construction unique :
- Semez depuis des captures live. Inventoriez ce que le navigateur reçoit sur la page de paiement en production, pas une liste de vendors ni un export de tag manager.
- Réduisez la surface. Retirez les scripts qui n'ont pas besoin de tourner sur la page de paiement. Moins de scripts autorisés, c'est moins de registres à garder honnêtes.
- Autorisez avant l'exposition. Assignez un owner, écrivez la justification et la limite d'accès aux données, et définissez le statut avant que le script n'arrive sur le chemin de paiement.
- Réautorisez à chaque changement. Quand le payload servi par un script change de hash, l'autorisation antérieure ne couvre plus le nouveau contenu. Traitez chaque changement comme une nouvelle décision d'approbation.
- Planifiez une revue permanente. Lancez une revue récurrente pour garder le texte de justification précis à mesure que les scripts évoluent, et pour que rien ne reste indéfiniment en
pending.
L'étape quatre est celle où les processus manuels s'effondrent. Un tag tiers moderne peut servir un payload différent selon la localisation, le navigateur ou l'heure du jour. Capturer à la main chaque changement de hash sur chaque script à chaque chargement n'est pas réaliste. C'est pourquoi l'inventaire doit être câblé à un mécanisme de détection plutôt que retapé par un humain chaque semaine.
Où cside s'insère dans le workflow d'inventaire
cside construit l'inventaire depuis la couche navigateur — il enregistre les scripts que les navigateurs de vrais clients reçoivent réellement, y compris les chargements inline et de quatrième partie que les listes de vendors et les exports de tag manager ne montrent jamais. Chaque entrée porte la source, le payload servi, un hash de contenu, et des timestamps first-seen / last-seen, donc l'inventaire reflète la production plutôt qu'un instantané périmé.
Côté autorisation, cside stocke l'owner, la justification et le contexte d'accès aux données à côté de chaque script, et signale quand le contenu servi d'un script change pour que l'autorisation antérieure puisse être revue face au nouveau payload. Cela transforme 6.4.3 d'un tableur trimestriel en un registre vivant avec des exports prêts pour QSA, et alimente la preuve de détection de changements qu'exige 11.6.1. Voir cside PCI Shield pour la vue plateforme.
Lectures complémentaires sur cside
- Comment se conformer à PCI 6.4.3 et 11.6.1
- Ce que les QSAs doivent regarder dans 6.4.3 et 11.6.1
- Guide de conformité client-side PCI DSS 4.0.1
- cside PCI Shield
Au 2026-06-18, considérez ceci comme un guide opérationnel, pas comme un conseil juridique. Confirmez le libellé exact du contrôle avec votre QSA, votre conseil juridique ou votre responsable des risques.
