CentralCSP
FonctionnalitésPCI DSS

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.

Dernière mise à jour:

Une règle de justification justifie tout script dont l'URL correspond à un motif, pour que les approbations de routine ne consomment pas de temps de revue. Utilisez-les pour votre propre origine et pour les prestataires que vous avez déjà validés.

Nécessite le rôle Manager sur le site.

Ajouter une règle

PCI DSS > Règles de justification > Ajouter une règle. Quatre champs :

ChampNotes
NomUn libellé, par exemple Prestataire de paiement approuvé
Motif d'URL de script* est le seul joker, il correspond à n'importe quels caractères y compris les barres obliques
JustificationObligatoire. C'est ce texte que lit un évaluateur
TagsFacultatif, appliqués à chaque script capté par la règle
https://js.stripe.com/*

Écrivez la justification comme une raison métier. « Tokenisation de carte pour le paiement, contrat revu en 2026-03 » est une preuve, « de confiance » n'en est pas une.

Jusqu'à 200 règles par site web.

La liste des règles de justification dans leur ordre de création, chaque règle montrant son motif d'URL, sa justification écrite et son étiquette, la dernière règle désactivée

Les motifs doivent correspondre à l'URL entière

Même syntaxe que les pages de paiement, et le même piège : le motif est ancré, il doit donc correspondre à l'URL de script entière.

https://*.stripe.com/* correspond à https://js.stripe.com/v3/. Un simple stripe.com ne correspond à rien du tout.

Les règles s'appliquent rétroactivement

Créer ou modifier une règle reconstruit l'inventaire immédiatement, et la règle justifie les scripts déjà présents dans l'inventaire, pas seulement ceux détectés plus tard.

C'est ce qui rend les règles utiles à écrire en premier. Ajoutez vos règles avant de commencer la revue à la main, et la liste manuelle sera ce qui reste.

Priorité

Les règles sont évaluées dans l'ordre de création, de la plus ancienne à la plus récente, et la première correspondance gagne. Les règles suivantes ne sont pas évaluées. L'interface n'offre aucun contrôle de priorité, donc si deux règles peuvent capter le même script, c'est la plus ancienne qui s'applique.

Ce qu'une règle écrase et ce qu'elle n'écrase pas :

État du scriptLa règle s'applique ?
UnreviewedOui
Needs review, hash modifiéOui
Justifié à la main, hash inchangéNon, votre formulation est conservée
Justifié à la main, puis hash modifiéOui, la règle prend le relais
RejectedJamais

Un changement de hash confie une justification manuelle à une règle

Quand un script justifié à la main change de hash, une règle correspondante le reprend à son compte : la justification de la règle remplace la vôtre et l'enregistrement cesse de vous nommer comme relecteur. Si un script précis doit recevoir une décision humaine à chaque changement, assurez-vous qu'aucun motif de règle ne le couvre.

Le rejet est le seul absolu. Un script que vous avez marqué comme rejeté n'est jamais rejustifié par l'automatisation.

Désactiver et supprimer

L'interrupteur Activé empêche une règle de capter quoi que ce soit de nouveau. Il ne dé-justifie pas les scripts que la règle avait déjà justifiés. Ils gardent leur statut et leur justification jusqu'à ce que quelque chose les rende examinables à nouveau, un changement de hash par exemple.

La suppression se comporte de la même façon, et les entrées existantes restent dans le registre. Une bizarrerie : supprimer une règle ne déclenche pas de reconstruction, même si rien ne changerait de toute façon pour les scripts existants.

Quand une règle cesse de fonctionner

Une règle dont le motif stocké ne compile plus est ignorée silencieusement pendant la réconciliation, et ses scripts restent non examinés. Si une règle que vous croyez active laisse des scripts dans Action requise, réenregistrez-la pour revalider le motif.

Étapes suivantes

On this page