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
- 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. Il n'y a aucun moyen de consigner une décision sans lui, et c'est le but : 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.
Écrire des justifications utilisables par un évaluateur
La justification doit répondre à la question de savoir 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 ou rejeter
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 Needs review et revient vers vous.
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 définitif face à l'automatisation : aucune règle de justification ne rejustifiera jamais un script rejeté.
Traiter un hash qui a changé
Needs review 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 detected | Vu pour la première fois dans le périmètre |
| Script hash changed | Le contenu servi à cette URL a changé |
| Justification rule applied | Une règle l'a justifié automatiquement |
| Manual justification saved | Une personne l'a justifié |
| Script marked rejected | Une personne l'a rejeté |
| Script left the payment-page scope | Retiré, ne correspond plus au périmètre |
| Script returned to the payment-page scope | 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 de justification
Justifiez automatiquement les scripts de confiance par motif d'URL. Elles agissent rétroactivement, la première correspondance gagne, un rejet est définitif.