Justifier les scripts
Consignez pourquoi chaque script sur une page de paiement est autorisé, ou rejetez-le. Les deux décisions demandent un motif écrit et vont au registre.
Dernière mise à jour:
Chaque script du périmètre a besoin d'une décision : justifié, autrement dit il a sa place et voici pourquoi, ou rejeté, autrement dit il n'en a pas. Les deux sont consignés avec votre nom, l'horodatage, et le hash auquel la décision s'appliquait.
Nécessite le rôle Analyste sur le site, ou supérieur.
Prendre une décision
Parcourez la file d'examen ainsi :
- Ouvrez PCI DSS > Inventaire de scripts puis l'onglet Action requise.
- Cliquez sur un script pour ouvrir son panneau.
- Sous Décision de revue, choisissez Justifier ou Marquer comme rejeté.
- Écrivez la raison et enregistrez.
Le champ de texte est obligatoire, jusqu'à 4096 caractères. Impossible de consigner une décision sans ce texte, et c'est voulu : le texte est la preuve.
Une décision peut être révisée ensuite. Chaque révision est une nouvelle entrée de registre, pas un remplacement.
La décision se prend dans le bloc Décision de revue du panneau du script :
Écrire des justifications utilisables par un évaluateur
La justification doit expliquer pourquoi ce code a le droit de s'exécuter là où des données de carte sont saisies. Les bonnes nomment la fonction métier, le responsable, et la revue effectuée.
Bien : Stripe.js tokenise les champs de carte. Nécessaire au paiement. Due diligence fournisseur faite en 2026-02, responsable équipe Paiements.
Sans intérêt : nécessaire, ok, tiers.
Vous écrivez pour quelqu'un qui ne connaît pas votre stack et qui va en lire quelques centaines.
Justifier, rejeter ou sortir du périmètre
Justifier consigne que le script a sa place, et épingle la décision au hash actuel du script. Si le contenu servi à cette URL change plus tard, le script passe en À réexaminer et revient vers vous, même si une règle d'inventaire couvre la même URL. Une règle ne peut pas approuver un hash que vous n'avez pas lu.
Rejeter consigne qu'il n'a pas sa place.
Rejeter ne bloque pas le script
Marquer un script comme rejeté est l'enregistrement de votre décision, rien de plus. Le script continue de se charger. Retirez-le de la page ou bloquez-le dans votre CSP dans une action distincte, puis confirmez qu'il cesse d'apparaître.
Le rejet est une décision humaine, et rien d'autre. Aucune règle d'inventaire ne rejette un script, et aucune ne réapprouve celui que vous avez rejeté. Une règle qui correspond à un script déjà décidé le laisse tranquille, dans un sens comme dans l'autre.
Rejeter n'est pas non plus la même chose que sortir un script du périmètre. Si le script n'est pas le vôtre du tout, une règle Exclure est l'enregistrement honnête, parce que rejeter affirme qu'un script non autorisé s'exécute sur votre page de paiement.
Traiter un hash qui a changé
À réexaminer signifie qu'un script que vous aviez justifié sert désormais un contenu différent.
Ne rejustifiez pas par réflexe. La question est de savoir si le changement était attendu :
- Votre propre bundle après un déploiement : attendu, rejustifiez.
- Un script fournisseur qui correspond à une version qu'il a annoncée : vérifiez, puis rejustifiez.
- Un script fournisseur qui change sans version correspondante : enquêtez avant de décider. C'est le cas pour lequel l'exigence existe.
L'onglet Historique des hashes du script donne la séquence complète des hashes avec première et dernière apparition, et c'est ainsi que vous distinguez une cadence de routine d'une anomalie.
La piste d'historique
La section Historique enregistre chaque événement sur le script :
| Événement | Signification |
|---|---|
| Script détecté | Vu pour la première fois dans le périmètre |
| Empreinte du script modifiée | Le contenu servi à cette URL a changé |
| Règle de justification appliquée | Une règle Approuver l'a justifié automatiquement |
| Exclu du périmètre par une règle | Une règle Exclure l'a sorti du périmètre PCI |
| Justification manuelle enregistrée | Une personne l'a justifié |
| Script marqué comme rejeté | Une personne l'a rejeté |
| Le script a quitté le périmètre des pages de paiement | Retiré, ne correspond plus au périmètre |
| Le script est revenu dans le périmètre des pages de paiement | De retour dans le périmètre |
Chaque entrée porte l'horodatage, qui a agi, le texte écrit, et le hash du moment. Les événements automatiques s'affichent comme tels au lieu de nommer une personne.
Le registre est en ajout seul. Rien dans le produit ne modifie ni ne supprime une entrée, et l'historique survit à un script qui quitte le périmètre puis y revient. Il n'est pas scellé ni signé cryptographiquement, décrivez-le donc à un évaluateur comme un journal applicatif en ajout seul plutôt que comme inaltérable.
Supprimer un utilisateur anonymise son identifiant sur les entrées passées. Les événements, eux, restent.
Tags
Les Managers peuvent attacher des tags pour classer les scripts, par exemple par responsable ou par catégorie de fournisseur. L'enregistrement remplace tout le jeu de tags de ce script. Voir Tags.
Étapes suivantes
Réconciliation
Comment l'inventaire de scripts est reconstruit à partir des reports de hash, quand cela tourne seul, et quand une actualisation manuelle vaut le coup.
Règles d'inventaire
Décidez des scripts par motif d'URL. Approuvez ceux que vous validez, sortez du périmètre PCI les logiciels du visiteur, sans toucher aux décisions humaines.