Modifications de la page de paiement : quoi surveiller et quand

Surveiller les modifications de la page de paiement, c'est savoir, à temps pour agir, quand un élément de cette page s'est mis à fonctionner d'une manière que la boutique n'a pas autorisée. Cela inclut les fichiers sur le serveur, les scripts que la page charge, les en-têtes de sécurité et, surtout, ce qui s'affiche sur l'écran de l'acheteur. Chaque couche demande une méthode différente, et aucune méthode ne voit les quatre.

Pourquoi surveiller la page de paiement et pas seulement le site

La page de paiement est la seule où une attaque se transforme immédiatement en argent. Un code qui copie la carte ou remplace le QR du Pix (le système de paiement instantané de la Banque centrale du Brésil) n'a besoin de fonctionner qu'à cet endroit, et c'est pourquoi il reste généralement inactif sur le reste du site. En septembre 2026, des boutiques brésiliennes touchées par un code de ce type ont d'abord vu un symptôme commercial, la hausse des abandons sur le Pix, avant toute alerte technique.

Surveiller la page de paiement est aussi une obligation. Depuis le 31 mars 2025, l'exigence 11.6.1 du PCI DSS demande un mécanisme qui détecte les modifications non autorisées du contenu de la page et des en-têtes de sécurité, avec une vérification au moins hebdomadaire ou à la fréquence définie par une analyse de risque propre à l'entreprise.

Quoi surveiller : les quatre couches

1. Les fichiers sur le serveur

Les fichiers de la plateforme, du thème et des plugins. Une modification en dehors d'une mise en ligne planifiée est le signe le plus classique d'une intrusion.

Ce que cette couche ne voit pas : un code qui arrive d'une adresse externe et n'existe que dans le navigateur.

2. Les scripts chargés par la page

La liste de tout ce que la page de paiement appelle : fichiers propres, outils d'analyse, chat, pixel publicitaire, scripts du prestataire de paiement. C'est l'inventaire demandé par l'exigence 6.4.3 du PCI DSS, avec un responsable, une raison d'être et une garantie d'intégrité pour chaque élément.

Ce que cette couche ne voit pas : un script déjà autorisé qui change de comportement sans changer de nom, ou une extension dans le navigateur du client.

3. Les en-têtes de sécurité

Les instructions que le serveur envoie au navigateur avec la page, comme la politique qui définit d'où les scripts peuvent être chargés et vers où les données peuvent être envoyées. Si quelqu'un assouplit cette politique, la porte reste ouverte sans qu'aucun fichier ne change.

Ce que cette couche ne voit pas : une attaque qui passe par un service déjà autorisé. En juin 2026, des chercheurs ont décrit un code de vol de données de carte qui s'appuyait sur un service de paiement connu, précisément pour passer à travers les politiques qui lui faisaient confiance.

4. Ce que montre l'écran du client

Le QR du Pix, le texte du Pix Copia e Cola (le code de paiement en texte que le client copie puis colle dans l'application de sa banque), la linha digitável (le numéro du boleto) du boleto (le bordereau de paiement bancaire brésilien), l'adresse du portefeuille, le formulaire qui reçoit la carte de crédit et la carte de débit, et la destination vers laquelle ce formulaire envoie les données. C'est ici que l'arnaque a lieu et c'est ici qu'elle apparaît en entier.

Ce que cette couche demande : comparer ce qui est à l'écran avec ce que la boutique a émis, et pas seulement enregistrer qu'un élément a changé.

À quelle fréquence

Il n'existe pas de fréquence unique. La règle pratique consiste à en fixer une par couche :

• Fichiers sur le serveur : à chaque mise en ligne et chaque jour, avec une alerte immédiate pour toute modification hors mise en ligne.
• Scripts et en-têtes : en continu, avec une revue humaine au moins hebdomadaire, ce qui est le minimum de la 11.6.1.
• Écran du client : à chaque chargement de la page de paiement. Un QR remplacé le mardi à 10 h a déjà reçu de l'argent à 10 h 01.

Les méthodes et ce que chacune voit

• Surveillance des fichiers sur le serveur. Efficace contre les intrusions qui touchent au code de la boutique. Aveugle à ce qui est assemblé dans le navigateur.
• Analyse externe par robot. Un robot ouvre la page de paiement de temps en temps et enregistre ce qu'elle charge. Cela aide à bâtir l'inventaire, mais le robot ne voit que sa propre session, et un code malveillant peut se comporter autrement face à des visiteurs qui ont l'air automatisés.
• Rapports du navigateur sur la politique de sécurité. Le navigateur du client signale quand un élément a tenté de se charger depuis un endroit non autorisé. Il montre les tentatives bloquées, pas ce qui est passé par une adresse autorisée.
• Script de surveillance sur la page elle-même. Il s'exécute dans le navigateur du vrai client et voit ce que la page a réellement chargé et modifié après son ouverture.
• Vérification de la donnée de paiement. Un cran plus loin que la précédente : en plus de voir que le QR a changé, elle le compare au QR émis par la boutique et bloque s'il ne correspond pas.

Les trois premières méthodes disent « quelque chose a changé ». Seule la dernière dit « le client est sur le point de payer la mauvaise personne ».

Comment créer des alertes que quelqu'un traite

1. Définissez ce qui est autorisé. Sans liste des scripts et des destinations attendus, chaque alerte n'est que du bruit.
2. Séparez l'urgent de la routine. Un nouveau script sur la page de paiement et un QR divergent sont urgents. Un changement de version d'un outil d'analyse relève de la routine, à revoir dans la semaine.
3. Envoyez l'urgent à qui peut agir. Un canal avec une astreinte, pas une boîte e-mail.
4. Croisez signaux techniques et commerciaux. Le taux de Pix en attente, l'abandon sur la page de paiement et les réclamations de paiement sans commande comptent autant qu'une alerte sur un fichier.
5. Conservez les preuves. Date, page, ce qui a changé et qui l'a approuvé. C'est ce que demande l'auditeur PCI DSS et ce qui aide à expliquer l'incident au client.

Liste de contrôle rapide

• Liste des scripts de la page de paiement, avec responsable et raison d'être.
• Alerte pour tout fichier modifié hors mise en ligne.
• Politique de sécurité du contenu avec rapports activés.
• Surveillance dans le navigateur du vrai client, pas seulement par robot.
• Vérification du QR, du Copia e Cola, de la linha digitável et du formulaire de carte par rapport à ce que la boutique a émis.
• Tableau de bord quotidien avec le taux de Pix en attente.
• Trace de chaque modification approuvée et de chaque alerte traitée.

Pour le contexte des attaques que cette surveillance permet d'éviter, lisez Magecart : définition et protection de l'e-commerce. Pour les exigences, voir scripts tiers sur la page de paiement.

Le rôle de Proteside

Proteside couvre la deuxième et la quatrième couche dans le navigateur de l'acheteur : il tient l'inventaire des scripts de la page de paiement et vérifie, à chaque commande, que le QR, le Copia e Cola, la linha digitável et le formulaire de carte sont bien ceux émis par la boutique. Si ce n'est pas le cas, il bloque le remplacement avant la confirmation, prévient la boutique et enregistre le cas comme preuve pour le PCI DSS. Voir comment ça marche.