PCI DSS

PCI Shield de cside utilise des contrôles de client-side security et de client-side protection pour protéger les pages de paiement contre Magecart, e-skimming, formjacking et d’autres attaques exécutées dans le navigateur du client. Cette page explique comment cside correspond aux exigences 6.4.3 et 11.6.1 de PCI DSS et comment configurer des preuves prêtes pour l’audit.

Qu’est-ce que PCI DSS ?

Le Payment Card Industry Data Security Standard (PCI DSS) est un ensemble de directives qui garantit la sécurité des transactions par carte à l’échelle mondiale. Créé par le PCI Security Standards Council, son objectif est de protéger contre le vol de données et la fraude dans les transactions par carte de débit et de crédit.

PCI DSS v4.0.1 introduit deux exigences qui régissent les scripts et les en-têtes délivrés au navigateur du titulaire de la carte sur les pages de paiement :

• 6.4.3 couvre l’autorisation, l’intégrité et l’inventaire des scripts.
• 11.6.1 couvre la détection des modifications et des altérations pour les en-têtes HTTP à impact sur la sécurité et le contenu des scripts des pages de paiement.

Vous pouvez consulter la spécification complète sur le site du PCI Security Standards Council.

Deux modes de déploiement, tous deux conformes

cside propose deux modes de surveillance. Les deux satisfont les exigences 6.4.3 et 11.6.1. Choisissez selon votre tolérance au risque et votre capacité à déployer des changements de code.

Méthode par scan (sans modification de code)

• Exécute de véritables conteneurs de navigateur (et non de simples requêtes HTTP) deux fois par jour sur l’ensemble du site et sur le parcours utilisateur menant à la page de paiement.
• Surveille les scripts au fur et à mesure que le DOM se rend, y compris les sous-requêtes et les ressources chargées tardivement que les scanners HTTP basiques manquent.
• Imite le comportement d’un utilisateur réel afin de capturer les scripts injectés dynamiquement et les ressources rotées par CDN.

Deux scans par jour dépassent l’exigence « au moins hebdomadaire » de 11.6.1 et satisfont l’attente d’inventaire périodique de 6.4.3.

Méthode par script (runtime, en ligne)

• Se charge en ligne dans la session réelle de l’utilisateur et enregistre chaque script et chaque action de script en temps réel dans l’infrastructure de cside.
• Fournit une visibilité au niveau des requêtes dans le tableau de bord.
• Permet un blocage granulaire : cside peut bloquer des actions spécifiques ou arrêter totalement des scripts.
• S’interopère avec CSP. cside empêche également les scripts malveillants d’injecter des directives CSP qui désactiveraient le script cside lui-même, un comportement que nous n’avons observé dans aucune autre solution du marché.

Exigence 6.4.3

Tous les scripts des pages de paiement qui sont chargés et exécutés dans le navigateur du consommateur sont gérés comme suit…

« Une méthode est mise en place pour confirmer que chaque script est autorisé. »

PCI DSS autorise les modèles d’autorisation a priori et a posteriori. cside prend en charge les deux :

• Méthode par scan : les scripts détectés sur la page de paiement et son parcours utilisateur apparaissent dans le tableau de bord PCI DSS pour revue et autorisation par un utilisateur identifié. Le tableau de bord et le journal d’audit consignent qui a autorisé chaque script et quand.
• Méthode par script : en plus de l’autorisation via le tableau de bord, cside peut techniquement empêcher l’exécution des scripts non autorisés ou d’actions spécifiques en runtime. Cela fonctionne en complément de CSP et continue de fonctionner même lorsqu’un attaquant tente d’injecter des directives CSP pour désactiver cside.

Les décisions d’autorisation, l’identité de la personne qui autorise et les horodatages sont écrits dans le journal d’audit et sont exportables pour votre QSA.

« Une méthode est mise en place pour assurer l’intégrité de chaque script. »

cside vérifie l’intégrité sur plusieurs axes plutôt que sur une simple comparaison de hash :

• Hachage du payload : le corps de chaque script est haché. Un nouveau hash déclenche l’ensemble du pipeline d’analyse.
• Pipeline d’analyse du contenu : les nouveaux payloads sont désobfusqués, mis en forme et évalués par notre moteur de règles propriétaire en Rust, des règles Yara, un LLM local à petit contexte, des modèles plus grands pour une analyse approfondie et une étape de revue humaine par l’équipe cside.
• Vérification des métadonnées de source : chaque source de script est confrontée à l’historique de l’émetteur SSL (pour repérer les tentatives de détournement), à l’historique d’enregistrement et de propriété du domaine, aux changements des enregistrements DNS et NS, au statut RPKI des adresses IP résolvantes (pour détecter les fuites BGP) et au reverse DNS pour repérer un chevauchement d’infrastructure avec des domaines malveillants connus.
• Contexte historique : cside conserve les hashs précédents servis derrière la même URL, de sorte que les modifications d’intégrité entre versions puissent être auditées. Le tableau de bord expose chaque variante de hash et rend le payload pour inspection.

« Un inventaire de tous les scripts est tenu, assorti d’une justification écrite, commerciale ou technique, indiquant pourquoi chacun est nécessaire. »

Le tableau de bord PCI DSS est conçu spécifiquement pour cette clause :

• Un inventaire en direct de chaque script détecté sur les pages de paiement, y compris l’objet parent qui a provoqué son chargement.
• Des justifications commerciales et techniques générées par IA à partir du payload et de son comportement (ce que le PCI SSC autorise explicitement), qu’un utilisateur revoit et confirme ensuite.
• Des entrées d’audit par script qui enregistrent qui a accepté ou modifié chaque justification, avec un historique complet des révisions.
• Des payloads mis en forme avec les API sensibles du navigateur surlignées en ligne pour que les relecteurs puissent décider en connaissance de cause.

Exigence 11.6.1

Un mécanisme de détection des modifications et des altérations est déployé…

« Pour alerter le personnel en cas de modification non autorisée des en-têtes HTTP à impact sur la sécurité et du contenu des scripts des pages de paiement tels que reçus par le navigateur du consommateur. »

cside capture les en-têtes et le contenu des scripts tels qu’ils arrivent dans un véritable navigateur, et non tels qu’ils sont renvoyés lors d’une requête côté serveur. C’est important car de nombreux sites servent des en-têtes et des scripts différents selon le User-Agent, l’empreinte TLS, la détection de bots et le routage géographique.

En-têtes à impact sur la sécurité surveillés :

• Content Security Policy
• Content Security Policy Report Only
• Report To
• Reporting Endpoints
• Strict Transport Security
• X-Frame-Options
• Cross-Origin Resource Policy
• Cross-Origin Opener Policy
• Cross-Origin Embedder Policy
• Permissions Policy
• X-Content-Type-Options
• X-Permitted-Cross-Domain-Policies
• Referrer Policy
• X-XSS-Protection

cside traite chaque changement de hash comme un nouveau script. Chaque fois que le payload change, le nouveau hash est automatiquement désobfusqué et passé dans l’ensemble du pipeline de détection. Les alertes ne sont pas déclenchées par le changement lui-même, elles sont déclenchées lorsque l’analyse détecte quelque chose d’anormal.

Concrètement :

• Chaque changement de hash est analysé comme un nouveau script. Les nouveaux scripts, les scripts supprimés, les payloads modifiés et les déviations comportementales (nouvelles destinations réseau, nouvelles API du DOM, nouvelles surfaces de stockage accédées) sont tous capturés et évalués. La détection ne repose pas sur la signature du script parent.
• Les alertes se déclenchent sur le mauvais comportement. Si une variante de hash se comporte de manière anormale ou qu’un élément préoccupant émerge (sources ou payloads connus comme malveillants, tentatives de manipulation de CSP, comportement d’exfiltration, scores de menace au-delà du seuil, nouveaux motifs d’obfuscation), cside alerte en temps réel via les endpoints de notification configurés.
• L’inventaire courant est rapporté périodiquement. Le rapport PDF hebdomadaire (configurable en quotidien) liste chaque script détecté sur les pages de paiement, chaque URL de page de paiement, chaque changement d’en-tête de sécurité et chaque justification commerciale avec son auteur. Cela satisfait la clause « au moins hebdomadaire » de 11.6.1.

Cela dépasse le standard. 11.6.1 exige une évaluation périodique ; cside exécute une analyse par hash en continu et superpose des alertes immédiates.

« Le mécanisme est configuré pour évaluer les en-têtes HTTP et les pages de paiement reçus. »

cside évalue les en-têtes et le payload tels qu’ils sont rendus dans le navigateur. Lorsque les en-têtes ne sont normalement pas exposés à un script au sein de la page, cside utilise le contexte du navigateur pour les obtenir. Si vos pages de paiement sont derrière un VPN ou dans un environnement verrouillé, cside fournit une IP statique pour que le scanner puisse les atteindre.

« Les fonctions du mécanisme sont exécutées au moins hebdomadairement, ou périodiquement à la fréquence définie par l’analyse de risque ciblée de l’entité (Exigence 12.3.1). »

• La méthode par scan s’exécute deux fois par jour.
• La méthode par script s’exécute en continu, dans la session réelle de l’utilisateur.
• Un rapport PDF hebdomadaire est envoyé par défaut, récapitulant tous les changements d’en-têtes de sécurité, chaque script détecté sur les pages de paiement, chaque URL de page de paiement et chaque justification (y compris son auteur). Cette cadence peut être portée à quotidien.
• Les détections de scripts malveillants déclenchent une alerte immédiate, en dehors du rapport hebdomadaire.

Approbation QSA

cside affiche un taux d’approbation QSA de 100 %. Nous travaillons directement avec de grandes banques, des prestataires de paiement et des cabinets QSA. Un livre blanc signé par VikingCloud est disponible sur notre trust center, et la plupart des cabinets QSA ont revu la solution.

En quoi cside va au-delà de l’exigence

PCI DSS fixe un plancher, pas un plafond. Les capacités suivantes dépassent la lettre de 6.4.3 et 11.6.1 :

• Pipeline de détection en couches : règles Yara, moteur de règles propriétaire en Rust, LLMs à petit contexte, grands LLMs et revue humaine. La plupart des concurrents dépendent uniquement de flux de menaces tiers.
• Contrôles de provenance de la source : deltas d’émetteur SSL, historique de domaine et DNS, validation RPKI et reverse DNS sur les IPs résolvantes.
• Résistance à la manipulation de CSP : cside détecte et bloque les tentatives de scripts malveillants visant à injecter des directives CSP qui désactiveraient le script cside.
• Visibilité au niveau des requêtes : chaque sous-requête effectuée par un script est enregistrée avec son objet parent.
• Désobfuscation et mise en forme : le tableau de bord affiche la version lisible par l’humain de chaque payload avec les API sensibles surlignées.
• Recherche continue sur le web public : cside étudie des sites qui ne sont pas clients pour repérer de nouvelles attaques avant qu’elles n’atteignent les pages de paiement des clients.

Configurer le tableau de bord PCI DSS

Accéder aux paramètres PCI DSS

Pour accéder au tableau de bord PCI DSS, ouvrez le tableau de bord puis :

1. Sélectionnez votre domaine dans la barre latérale
2. Sélectionnez PCI DSS

Ajouter des pages de paiement

Avant de commencer à utiliser le tableau de bord PCI DSS, vous devez identifier vos pages de paiement. Cela permet de filtrer les données pour vous concentrer sur les scripts et les en-têtes liés au paiement.

1. Cliquez sur Add a Payment Page ou + Add Payment Page
2. Saisissez l’URL de la page de paiement au format de correspondance de motifs de scripts

3. Cliquez sur Create

Configuration page vs modal

Il existe deux options principales de configuration selon votre implémentation du paiement :

Configuration page

Choisissez cette option si vos pages de paiement :

• Sont rendues côté serveur (SSR)
• Se chargent via un rechargement ou une navigation de page
• Sont isolées des scripts présents durant la navigation côté client

Cette configuration filtre la liste des scripts pour n’afficher que ceux présents sur les pages de paiement désignées.

Configuration modal

Choisissez cette option si vos formulaires de paiement sont implémentés via :

• Des fenêtres modales
• Des widgets en popup
• Des surimpressions de paywall
• Toute UI dynamique où les paiements peuvent être traités sur plusieurs pages

Cette configuration surveille les scripts sur l’ensemble de votre application, puisque les formulaires de paiement peuvent apparaître sur n’importe quelle page.

Configurez-la avec un sélecteur CSS qui identifie votre modal ou votre formulaire de paiement.

Exemple de sélecteur :

#pay

Le tableau de bord affichera tous les scripts susceptibles d’interagir avec le formulaire de paiement lorsqu’il est actif.

Questions fréquentes

Que demandent les exigences 6.4.3 et 11.6.1 de PCI DSS ?

L’exigence PCI DSS 6.4.3 demande que les scripts des pages de paiement soient autorisés, contrôlés pour leur intégrité, inventoriés et justifiés. L’exigence 11.6.1 demande une détection des changements et des altérations pour les en-têtes HTTP à impact sécurité et le contenu des scripts des pages de paiement tels que reçus par le navigateur du consommateur.

Comment la client-side security protège-t-elle les pages de paiement ?

La client-side security protège les pages de paiement en surveillant les scripts exécutés dans le navigateur, en détectant les changements non autorisés et en alertant lorsque le comportement d’un script suggère un vol de données ou une altération. cside apporte une visibilité runtime pour voir quels scripts tiers se chargent, ce qu’ils demandent et s’ils interagissent avec des parcours de paiement sensibles.

Comment cside traite Magecart, e-skimming et formjacking ?

cside analyse les payloads de scripts, les sous-requêtes, les métadonnées de source et le comportement runtime pour détecter les signes de Magecart, e-skimming, formjacking et d’attaques similaires basées sur le navigateur. Lorsque cside détecte un comportement malveillant, il peut alerter votre équipe et, en mode script, bloquer le script ou certaines actions.

Le mode scan seul suffit-il pour PCI DSS ?

Oui. La méthode par scan est conçue pour satisfaire les attentes d’inventaire périodique et de détection des changements de PCI DSS 6.4.3 et 11.6.1. La méthode par script ajoute une surveillance runtime continue et un blocage pour les équipes qui veulent une client-side protection plus forte que le minimum de conformité.

Comment les rapports cside aident-ils les QSAs et les preuves d’audit ?

Les rapports cside affichent les URLs de pages de paiement, les scripts détectés, les changements d’en-têtes, les décisions d’autorisation, les justifications métier, les auteurs et les horodatages. Cela donne aux QSAs une preuve que les scripts des pages de paiement sont suivis et revus, sans dépendance à des captures d’écran ou feuilles de calcul manuelles.

cside applique-t-il des contrôles ou se contente-t-il de surveiller ?

Les deux, selon le mode. La méthode par script peut bloquer des scripts et des actions spécifiques en runtime et bloque également les tentatives d’injection CSP visant à désactiver la surveillance. La méthode par scan est, par conception, uniquement de surveillance. PCI DSS autorise explicitement les scanners en post-autorisation, et le PCI SSC l’a confirmé directement.

Dans quelle mesure la détection est-elle en temps réel ?

La méthode par script s’exécute en ligne dans la session de l’utilisateur et enveloppe la plupart des API du navigateur pour observer la façon dont les scripts mutent le DOM ; l’analyse a donc lieu pendant l’exécution des scripts. Le même hash de payload n’est pas analysé deux fois car cela n’apporterait rien en matière de sécurité. 11.6.1 n’exige pas une surveillance de 100 % des sessions ; une évaluation périodique suffit, et cside répond aussi bien au critère périodique qu’au critère continu.

Comment cside gère-t-il les attaques nouvelles ou obfusquées ?

La détection ne repose pas sur la signature du script parent. cside enregistre chaque sous-requête effectuée par un script, désobfusque les payloads avant évaluation et exécute une analyse approfondie par IA sur tout ce qui dépasse son seuil de risque. Les payloads nouveaux et zero-day sont un objectif de conception spécifique. Consultez Détection des menaces pour le pipeline de détection complet.

Comment les justifications commerciales sont-elles suivies ?

Le tableau de bord PCI DSS enregistre chaque justification dans l’interface et dans le journal d’audit, y compris qui l’a rédigée ou modifiée et quand. Les justifications générées par IA sont explicitement autorisées par le PCI SSC et sont présentées au relecteur pour confirmation, plutôt qu’acceptées automatiquement.

Pages associées

• Détection des menaces
• Détection des vulnérabilités
• Journaux d’audit
• Notifications