# DataFirefly Skimming Guard: anti-skimming and file integrity

> Overview DataFirefly Skimming Guard monitors the code served to the customers of your PrestaShop 8 or 9 shop: files, database, the HTML sent on payment pages and what the browser…

- Page: <https://www.datafirefly.com/en/documentation/dfskimguard/>
- Language: en
- Last updated: 2026-09-30
- Other languages: [fr](https://www.datafirefly.com/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: <https://www.datafirefly.com/en/documentation/llms.txt>

## Overview

DataFirefly Skimming Guard monitors the code served to the customers of your PrestaShop 8 or 9 shop: files, database, the HTML sent on payment pages and what the browser does at checkout. It detects injected scripts that copy card numbers (Magecart-style attacks), modified or added files and PrestaShop core files that differ from the official release. It complements [DataFirefly Admin Shield](https://www.datafirefly.com/en/product/prestashop-back-office-security/), which protects the back office login.

## Installation

1. In the back office, open **Modules > Module Manager > Upload a module** and upload `dfskimguard-1.2.1.zip`.
2. Open the module. It is also available under **Advanced Parameters > Skimming Guard**.
3. Click **Scan now**. The first scan records the reference of your files: one SHA-256 fingerprint per file, and a copy of theme files, module views and entry points.
4. Set up the scheduled task (see below).
5. Send a test alert from the overview to check delivery.

A reference of 16,000 files takes less than a minute on a typical server. On hosting limited to 30 seconds per request, the scan splits itself into short steps.

## Scheduled task

Scans run in the background, never during a customer visit. Three options:

- **Cron URL**: copy the URL shown in the _Scheduled task_ block and call it every 15 minutes from your hosting cron manager. The URL contains a secret token.
- **Command line**: with SSH access, run `php modules/dfskimguard/cli.php`. The `--full` option runs a complete scan in one go, with no time limit.
- **PrestaShop cronjobs module**: if you use it, the task runs every hour.

Each run starts or resumes the file scan, scans the database once an hour, checks the PrestaShop core once a week and third-party script content once a day.

## Overview tab

The banner at the top of every tab shows a security score from 0 to 100 and a sentence summing up the situation, with shortcuts to what is still open. The overview lists two groups of checks, failing items first:

- **Protection setup**: recent reference, scheduled task running, alert recipients, learning finished, card data blocking, Content Security Policy, core check, payment script justifications.
- **Shop hardening**: debug mode, install folder, admin folder name, dangerous files reachable from the web (SQL or ZIP backups, phpinfo, adminer, .git, .env, PHPUnit `eval-stdin.php`), SSL on every page, PHP version, configuration file permissions.

Each failing item explains how to fix it.

## Checkout protection

### Inspection of the served HTML

On cart, checkout and payment module pages, the module reads the HTML PrestaShop produces. It records every external script, iframe, form target and domain referenced in an inline script, and applies signatures for obfuscated code (`eval(atob(...))`, `new Function`, `fromCharCode` chains, script loaders, developer tools detection). By default each page is inspected at most once every 5 minutes. Adjust the interval in the settings, or monitor every page of the shop.

### Browser sentinel

A 5.5 KB script is injected first in the `` of monitored pages. It reports unknown domains contacted by the page and, on payment pages, spots a valid card number sent to a domain that is not approved, even base64-encoded. The number is never sent to the server. To filter browser extensions, an unknown domain only alerts after 3 distinct visitors (adjustable); an attempt to send a card number alerts the first time.

### Card data blocking

Option **Block card data sent to unknown domains**: the request is cancelled when it contains a card number and targets a domain that is not approved. Turn it on once the learning period is over and your payment providers are approved.

### Content Security Policy

The module can send a CSP built from approved domains on monitored pages. Start with **Report only**, then switch to **Enforce** when no unexpected domain shows up.

In Enforce mode, any domain that is not approved is blocked, including a new payment provider. Approve it before turning it on.

### Learning period

For 48 hours after installation, low-risk third-party scripts and domains are approved without alerts. Suspicious items still alert. Restart learning after a theme or payment method change with **Learn for 48 hours**.

### Trusted domains

A built-in list covers common providers (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). Add your own domains in the settings, one per line; subdomains are included.

## Scripts and domains tab

The tab lists every item seen on your pages with its type, domain, page, risk score and number of hits. Three actions:

- **Approve**: the item and its domain join the trusted list (sentinel and CSP). For a payment page script, a window asks for the justification.
- **Malicious**: the domain is blocked by the sentinel and excluded from the CSP. If it shows up again, a critical alert is sent.
- **Delete**: removes the item from the inventory.

## File integrity

### What is monitored

Default extensions: php, phtml, php5, php7, phar, inc, js, mjs, tpl, twig, html, htm, htaccess, ini, svg, ico. Default excluded paths: var, cache, img, upload, download, .git, node_modules, theme caches and admin folder backups. The `{admin}` token is replaced by the name of your admin folder.

A file is considered unchanged when its size, modification time and inode change time have not moved. The inode change time cannot be forged with `touch`. A full rehash runs every 7 days (adjustable).

### Signatures

Every new or modified file goes through the signatures: known web shells, `eval` on decoded or request data, system commands from request data, PHP hidden in an image or .ico, include of a media file, `auto_prepend_file` added to .htaccess or .user.ini, media files executed as PHP, card fields read and sent over the network. A file with risk 70 or more triggers an immediate critical alert; other changes are grouped in one summary per scan.

### Files tab

- **See changes**: line-by-line diff between the approved version and the current file. In single-line minified JS, only the inserted fragment is shown.
- **Restore approved version**: puts the reference copy back. The modified version is kept in `var/dfskimguard/quarantine` as evidence.
- **Approve**: accepts the current file as the new reference. Multiple selection and **Approve all changes** are meant for after an update.
- **Quarantine**: moves a suspicious new file out of the shop. It can be restored.

### Update window

Before updating a module or the theme, click **I am updating my shop (2 h)**. For two hours, files changed without suspicious code become the new reference with no alert. A high-risk file still alerts.

## PrestaShop core check

The **PrestaShop core** tab downloads the official source of your version from GitHub, then compares the PHP, TPL and Twig files of `classes`, `controllers`, `src`, `config` and the PHP files of the admin folder. Line endings and the settings rewritten in `config/defines.inc.php` by the release build and debug mode are ignored. The module also reports unexpected PHP files in `classes`, `controllers` and `src`.

For each modified file: **Compare with official**, then **Restore official version**. An unexpected file can be quarantined. The check runs again automatically every week.

The server must be able to reach codeload.github.com. If outgoing connections are blocked, the check shows an error message and the rest of the module works normally.

## Database scan

Once an hour, the module looks for script tags, onerror or onload handlers, `javascript:` URLs and obfuscated code in configuration values, CMS pages, product, category, brand and supplier descriptions, and custom text blocks. A script pointing to an unknown or flagged domain raises the risk.

## PCI DSS 6.4.3 and 11.6.1

For each authorized payment page script, the module records the justification, the employee who authorized it and the date. The **Justify** button completes an already approved script. The module also monitors:

- the content of third-party scripts on payment pages, downloaded and scanned daily: an approved domain that starts serving malicious code triggers a critical alert;
- the security headers of payment pages set by PrestaShop and its modules (CSP, HSTS, X-Frame-Options, Permissions-Policy). Headers added by the web server are not visible from PHP.

The **PCI DSS report** button opens a printable report: justified inventory, active detection mechanisms with their last run, events of the last 90 days. **Export CSV** provides the raw inventory.

The report supports a PCI DSS assessment. It does not certify compliance: your acquirer or assessor remains the reference.

## Alerts

- **Email**: one or more addresses, adjustable minimum severity (info, warning, critical).
- **Webhook**: HTTPS URL receiving JSON with a Slack-compatible `text` field, usable with Teams or an in-house service.
- **Deduplication**: the same alert is not sent again for 60 minutes, and at most 20 alerts go out per hour (adjustable).
- **Back office banner**: as long as a critical alert is unread, a red banner shows at the top of the back office.
- **Weekly report**: score, alerts of the week, pending items and checks to fix.

## FAQ

### I get alerts after updating a module

Approve the changes in the Files tab, or use the update window next time.

### An unknown domain shows up and I do not recognize it

It may come from a visitor's browser extension. Until 3 distinct visitors have seen it, it does not alert. If it is a service you use, approve it; otherwise mark it as malicious.

### Where are copies and quarantine stored?

Reference copies are compressed in the database. Quarantine and the official PrestaShop archive are in `var/dfskimguard`, protected by an .htaccess. The module does not scan this folder.

### How do I start over?

The **Reset baseline** link erases the file reference; the next scan creates a new one. Quarantined files remain listed and can be restored.