# DataFirefly Skimming Guard : anti-skimming et intégrité des fichiers
> Présentation DataFirefly Skimming Guard surveille le code servi aux clients de votre boutique PrestaShop 8 ou 9 : les fichiers, la base de données, le HTML envoyé sur les pages…
- Page:
- Langue: fr
- Mis à jour le: 2026-09-30
- Autres langues: [en](https://www.datafirefly.com/en/documentation/dfskimguard/index.md), [es](https://www.datafirefly.com/es/documentation/dfskimguard/index.md), [de](https://www.datafirefly.com/de/documentation/dfskimguard/index.md), [it](https://www.datafirefly.com/it/documentation/dfskimguard/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfskimguard/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfskimguard/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfskimguard/index.md)
- Index:
## Présentation
DataFirefly Skimming Guard surveille le code servi aux clients de votre boutique PrestaShop 8 ou 9 : les fichiers, la base de données, le HTML envoyé sur les pages de paiement et ce que fait le navigateur au checkout. Il détecte les scripts injectés qui copient les numéros de carte (attaques de type Magecart), les fichiers modifiés ou ajoutés et les fichiers du cœur PrestaShop qui diffèrent de la version officielle. Il complète [DataFirefly Admin Shield](https://www.datafirefly.com/product/prestashop-back-office-security/), qui protège la connexion au back-office.
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules > Installer un module** et envoyez le fichier `dfskimguard-1.2.1.zip`.
2. Ouvrez le module. Il est aussi accessible dans **Paramètres avancés > Skimming Guard**.
3. Cliquez sur **Scanner maintenant**. La première analyse enregistre la référence de vos fichiers : une empreinte SHA-256 par fichier, et une copie des fichiers du thème, des vues de modules et des points d'entrée.
4. Configurez la tâche planifiée (voir plus bas).
5. Envoyez une alerte de test depuis la vue d'ensemble pour vérifier la réception.
Une référence de 16 000 fichiers se crée en moins d'une minute sur un serveur courant. Sur un hébergement limité à 30 secondes par requête, le scan se découpe automatiquement en étapes courtes.
## Tâche planifiée
Les analyses tournent en tâche de fond, jamais pendant la visite d'un client. Trois options :
- **URL cron** : copiez l'URL affichée dans le bloc _Tâche planifiée_ et appelez-la toutes les 15 minutes depuis le gestionnaire cron de votre hébergement. L'URL contient un jeton secret.
- **Ligne de commande** : avec un accès SSH, lancez `php modules/dfskimguard/cli.php`. L'option `--full` fait une analyse complète en une fois, sans limite de temps.
- **Module cronjobs de PrestaShop** : si vous l'utilisez, la tâche s'exécute toutes les heures.
Chaque exécution reprend ou lance l'analyse des fichiers, analyse la base de données une fois par heure, vérifie le cœur PrestaShop une fois par semaine et le contenu des scripts tiers une fois par jour.
## Vue d'ensemble
Le bandeau en haut de chaque onglet affiche un score de sécurité de 0 à 100 et une phrase qui résume la situation, avec des raccourcis vers ce qui reste à traiter. La vue d'ensemble liste deux séries de contrôles, les points en échec en premier :
- **Configuration de la protection** : référence récente, tâche planifiée active, destinataires des alertes, fin de l'apprentissage, blocage des données de carte, Content Security Policy, vérification du cœur, justification des scripts de paiement.
- **Durcissement de la boutique** : mode debug, dossier d'installation, nom du dossier admin, fichiers dangereux accessibles (sauvegardes SQL ou ZIP, phpinfo, adminer, .git, .env, `eval-stdin.php` de PHPUnit), SSL sur toutes les pages, version de PHP, permissions des fichiers de configuration.
Chaque point en échec indique comment le corriger.
## Protection du checkout
### Inspection du HTML servi
Sur le panier, le checkout et les pages de paiement des modules, le module lit le HTML produit par PrestaShop. Il inventorie chaque script externe, iframe, cible de formulaire et domaine cité dans un script inline, et applique des signatures de code obfusqué (`eval(atob(...))`, `new Function`, chaînes `fromCharCode`, chargeurs de scripts, détection des outils de développement). Par défaut, chaque page est inspectée au plus une fois toutes les 5 minutes. Réglez l'intervalle dans les paramètres, ou choisissez de surveiller toutes les pages de la boutique.
### Sentinelle navigateur
Un script de 5,5 Ko est injecté en premier dans le `` des pages surveillées. Il signale les domaines inconnus contactés par la page et, sur les pages de paiement, repère un numéro de carte valide envoyé vers un domaine non approuvé, même encodé en base64. Le numéro n'est jamais transmis au serveur. Pour filtrer les extensions de navigateur, un domaine inconnu n'alerte qu'après 3 visiteurs distincts (réglable) ; une tentative d'envoi de carte alerte dès la première fois.
### Blocage des données de carte
Option **Bloquer les données de carte envoyées à des domaines inconnus** : la requête est annulée quand elle contient un numéro de carte et vise un domaine non approuvé. Activez-la une fois la période d'apprentissage terminée et vos prestataires de paiement approuvés.
### Content Security Policy
Le module peut envoyer une CSP construite à partir des domaines approuvés sur les pages surveillées. Commencez en mode **Rapport uniquement**, puis passez en **Appliquer** quand aucun domaine inattendu n'apparaît.
En mode Appliquer, tout domaine non approuvé est bloqué, y compris un nouveau prestataire de paiement. Approuvez-le avant de l'activer.
### Période d'apprentissage
Pendant 48 heures après l'installation, les scripts et domaines tiers à faible risque sont approuvés sans alerte. Les éléments suspects alertent quand même. Relancez l'apprentissage après un changement de thème ou de moyen de paiement avec le bouton **Apprendre pendant 48 heures**.
### Domaines de confiance
Une liste intégrée couvre les prestataires courants (Stripe, PayPal, Braintree, Adyen, Mollie, Klarna, Checkout.com, Worldpay, PayPlug, Stancer, Lyra, PayZen, Systempay, Monetico, Alma, Scalapay, SumUp, Redsys, HiPay, Apple Pay, Google Pay, reCAPTCHA, hCaptcha, Turnstile, Google Analytics, Tag Manager, Meta). Ajoutez vos propres domaines dans les paramètres, un par ligne ; les sous-domaines sont inclus.
## Onglet Scripts et domaines
L'onglet liste chaque élément vu sur vos pages avec son type, son domaine, la page, un score de risque et le nombre de passages. Trois actions :
- **Approuver** : l'élément et son domaine rejoignent la liste de confiance (sentinelle et CSP). Pour un script des pages de paiement, une fenêtre demande la justification.
- **Malveillant** : le domaine est bloqué par la sentinelle et exclu de la CSP. Sa réapparition déclenche une alerte critique.
- **Supprimer** : retire l'élément de l'inventaire.
## Intégrité des fichiers
### Ce qui est surveillé
Extensions par défaut : php, phtml, php5, php7, phar, inc, js, mjs, tpl, twig, html, htm, htaccess, ini, svg, ico. Chemins exclus par défaut : var, cache, img, upload, download, .git, node_modules, les caches de thème et les sauvegardes du dossier admin. Le jeton `{admin}` est remplacé par le nom de votre dossier d'administration.
Un fichier est considéré inchangé si sa taille, sa date de modification et sa date de changement d'inode n'ont pas bougé. La date de changement d'inode ne se falsifie pas avec `touch`. Un recalcul complet des empreintes a lieu tous les 7 jours (réglable).
### Signatures
Chaque fichier nouveau ou modifié passe les signatures : web shells connus, `eval` sur des données décodées ou sur la requête, commandes système issues de la requête, PHP caché dans une image ou un .ico, include d'un fichier média, `auto_prepend_file` ajouté dans .htaccess ou .user.ini, fichiers média exécutés comme PHP, champs de carte lus et envoyés sur le réseau. Un fichier à risque 70 ou plus déclenche une alerte critique immédiate ; les autres changements sont regroupés dans un récapitulatif par analyse.
### Onglet Fichiers
- **Voir les changements** : diff ligne à ligne entre la version approuvée et le fichier actuel. Dans un JS minifié sur une seule ligne, seul le fragment inséré est affiché.
- **Restaurer la version approuvée** : remet la copie de référence en place. La version modifiée est conservée dans `var/dfskimguard/quarantine` comme preuve.
- **Approuver** : accepte le fichier actuel comme nouvelle référence. La sélection multiple et **Approuver toutes les modifications** servent après une mise à jour.
- **Quarantaine** : déplace un nouveau fichier suspect hors de la boutique. Il reste restaurable.
### Fenêtre de mise à jour
Avant de mettre à jour un module ou le thème, cliquez sur **Je mets à jour ma boutique (2 h)**. Pendant deux heures, les fichiers modifiés sans code suspect deviennent la nouvelle référence sans alerte. Un fichier à risque élevé alerte quand même.
## Vérification du cœur PrestaShop
L'onglet **Cœur PrestaShop** télécharge la source officielle de votre version depuis GitHub, puis compare les fichiers PHP, TPL et Twig de `classes`, `controllers`, `src`, `config` et les fichiers PHP du dossier admin. Les fins de ligne et les réglages que le build de release et le mode debug réécrivent dans `config/defines.inc.php` sont ignorés. Le module signale aussi les fichiers PHP inattendus dans `classes`, `controllers` et `src`.
Pour chaque fichier modifié : **Comparer avec l'officiel** puis **Restaurer la version officielle**. Un fichier inattendu peut être mis en quarantaine. La vérification se relance automatiquement chaque semaine.
Le serveur doit pouvoir joindre codeload.github.com. Si les connexions sortantes sont bloquées, la vérification affiche un message d'erreur et le reste du module fonctionne normalement.
## Analyse de la base de données
Une fois par heure, le module recherche des balises script, des gestionnaires onerror ou onload, des URL `javascript:` et du code obfusqué dans la configuration, les pages CMS, les descriptions de produits, de catégories, de marques et de fournisseurs, et les blocs de texte personnalisés. Un script vers un domaine inconnu ou flagué fait monter le risque.
## PCI DSS 6.4.3 et 11.6.1
Pour chaque script autorisé sur les pages de paiement, le module enregistre la justification, l'employé qui l'a autorisé et la date. Le bouton **Justifier** complète un script déjà approuvé. Le module surveille aussi :
- le contenu des scripts tiers des pages de paiement, téléchargés et analysés chaque jour : un domaine approuvé qui se met à servir du code malveillant déclenche une alerte critique ;
- les en-têtes de sécurité des pages de paiement posés par PrestaShop et ses modules (CSP, HSTS, X-Frame-Options, Permissions-Policy). Les en-têtes ajoutés par le serveur web ne sont pas visibles depuis PHP.
Le bouton **Rapport PCI DSS** ouvre un rapport imprimable : inventaire justifié, mécanismes de détection actifs avec leur dernière exécution, événements des 90 derniers jours. **Exporter en CSV** fournit l'inventaire brut.
Le rapport sert de support à une évaluation PCI DSS. Il ne certifie pas la conformité : votre acquéreur ou votre évaluateur reste la référence.
## Alertes
- **E-mail** : une ou plusieurs adresses, gravité minimale réglable (information, avertissement, critique).
- **Webhook** : URL HTTPS qui reçoit un JSON avec un champ `text` compatible Slack, utilisable avec Teams ou un service maison.
- **Anti-doublon** : la même alerte n'est pas renvoyée pendant 60 minutes, et 20 alertes au plus partent par heure (réglable).
- **Bandeau back-office** : tant qu'une alerte critique n'est pas lue, un bandeau rouge s'affiche en haut du back-office.
- **Rapport hebdomadaire** : score, alertes de la semaine, éléments en attente et points à corriger.
## Questions fréquentes
### Je reçois des alertes après la mise à jour d'un module
Approuvez les changements dans l'onglet Fichiers, ou utilisez la fenêtre de mise à jour la prochaine fois.
### Un domaine inconnu apparaît mais je ne le reconnais pas
Il peut venir d'une extension de navigateur d'un visiteur. Tant qu'il n'a pas été vu par 3 visiteurs distincts, il n'alerte pas. S'il s'agit d'un service que vous utilisez, approuvez-le ; sinon, marquez-le comme malveillant.
### Où sont stockées les copies et la quarantaine ?
Les copies de référence sont compressées en base de données. La quarantaine et l'archive officielle de PrestaShop sont dans `var/dfskimguard`, protégé par un .htaccess. Le module ne scanne pas ce dossier.
### Comment repartir de zéro ?
Le lien **Réinitialiser la référence** efface la référence des fichiers ; la prochaine analyse en crée une nouvelle. Les fichiers en quarantaine restent listés et restaurables.