Sécurité PrestaShop 2026 : webskimmers et infostealers côté serveur

Table des matières :

Webskimmers et infostealers côté serveur : ce qui change en 2026

Un webskimmer (souvent rangé sous le terme « Magecart ») est un code injecté dans le tunnel d’achat pour capturer les données de paiement au moment où l’utilisateur les saisit. Historiquement, on pense à une « injection JavaScript côté client ». En 2026, sur PrestaShop, le scénario le plus destructeur n’est pas l’inclusion d’un script tiers dans un template, mais la prise de contrôle serveur qui permet d’injecter dynamiquement le skimmer (via PHP) et de le faire varier selon l’IP, le pays, l’user-agent ou la présence d’un panier.

Cette bascule « côté serveur » change deux choses très concrètes :

L’injection devient conditionnelle et furtive : par exemple, le payload ne s’active que pour des IP résidentielles, sur les pages /commande et uniquement quand le DOM contient un champ carte (ou un identifiant de module de paiement). Résultat : vos tests QA (souvent faits depuis le bureau, avec un user-agent stable et des IP datacenter) peuvent ne rien voir.
Le skimmer n’est plus seulement du JavaScript “posé” dans un fichier : il peut être généré à la volée, compressé/minifié, puis servi via un endpoint PHP qui ressemble à un asset (/themes/…/assets/app.js?ver=...) et qui n’existe pas tel quel sur le disque.

Un infostealer côté serveur est un ensemble de mécanismes (backdoor PHP, webshell, cron, binaire, extension PHP, auto_prepend_file, etc.) visant à exfiltrer des secrets : credentials BO, cookies admin, clés API (PSP, ERP, transporteurs), dumps MySQL, .env/parameters.php, tokens OAuth, ou encore fichiers de configuration du reverse-proxy. À la différence d’un skimmer « pur », l’infostealer n’a pas besoin d’attendre le checkout : il vit dans l’infra, pivote et siphonne en continu.

Dans un contexte France/UE, la gravité dépasse la technique : un webskimmer peut faire basculer votre boutique dans une situation à risque PCI (données de carte potentiellement compromises) et un infostealer peut déclencher une gestion de crise RGPD (accès non autorisé à des données personnelles, parfois à grande échelle). La combinaison des deux est fréquente : l’attaquant vole d’abord des secrets (infostealer), puis monétise rapidement via la capture de cartes (webskimmer), tout en gardant une porte de retour.

Le point commun : ces attaques exploitent le fait que PrestaShop reste majoritairement un CMS PHP déployé comme un ensemble de fichiers modifiables (core + thèmes + modules + overrides). Tant que le runtime PHP a le droit d’écrire dans l’arborescence applicative, vous avez un vecteur de persistance. La plupart des boutiques compromises n’ont pas été « hackées par magie » : elles ont un mélange classique de dette de patching, de supply chain modules, et de mauvaises frontières d’exécution.

« The OWASP Top 10 is a standard awareness document for developers and web application security. » — OWASP, OWASP Top 10 : https://owasp.org/www-project-top-ten/

Chaîne d’infection typique sur une boutique PrestaShop (8.1–9.x)

Sur PrestaShop 8.1/8.2 et 9.x (PHP 8.2 ou 8.3), la chaîne d’infection « webskimmer + infostealer » suit souvent un pattern simple : accès initial (credential stuffing sur BO, FTP/SFTP réutilisé, clé SSH traînante, vulnérabilité module), puis écriture de fichiers (dropper dans modules/, override/, themes/, ou un pseudo-cache dans var/), puis injection checkout (Smarty/Twig, JS minifié/obfusqué), puis exfiltration (HTTP(S) sortant, DNS, webhook, voire SMTP).

Mini-scénario (réaliste en 2026)

Un compte BO (Back-Office) est compromis via mot de passe réutilisé (credential stuffing).
L’attaquant installe un module « utilitaire » (ou modifie un module existant) qui ajoute un hook actionFrontControllerSetMedia.
Le module sert un JS « normal » la plupart du temps, mais pour certains profils (langue FR + panier > 0 + URL de paiement), il ajoute une requête vers un endpoint PHP interne qui renvoie un JS skimmer obfusqué.
En parallèle, une tâche cron côté utilisateur exfiltre chaque nuit app/config/parameters.php, un dump partiel de ps_employee, et des clés API de transporteurs.

Ce qui rend ce scénario dangereux, c’est qu’il imite le fonctionnement normal de PrestaShop : hooks, assets, endpoints, et trafic réseau sortant “légitime” (HTTPS).

L’accès initial est rarement un 0-day du core. Le core PrestaShop a des limites, mais la surface d’attaque réelle est celle que vous ajoutez : modules non maintenus, endpoints exposés, contrôleurs custom, webservice activé « pour tester ». Si vous n’avez pas cadré le contrôle d’accès, vous retombez sur les classiques : IDOR, élévation de privilèges, impersonation mal bornée. Pour le versant applicatif pur, gardez une base solide sur les erreurs de contrôle d’accès (voir : Broken access control : prévenir IDOR et élévation de privilèges).

Côté persistance, les attaquants privilégient ce qui résiste aux mises à jour « à la va-vite ». Exemples concrets vus en prod :

auto_prepend_file activé via .user.ini dans la racine web (injecte du PHP sur chaque requête, puis écrit/sert du JS skimmer) ;
cron ajouté au niveau utilisateur (ou systemd --user) qui re-déploie des fichiers si vous les supprimez ;
module PrestaShop “légitime” dont un fichier a été modifié (controllers/front/, classes/, ajax.php) pour servir un payload ;
override discret qui s’accroche à un hook fréquent (displayHeader, actionFrontControllerSetMedia, displayPaymentTop) et ajoute un asset.

À noter : sur des hébergements mutualisés ou des serveurs historiquement gérés « à la main », la persistance passe aussi par des emplacements “gris” : dossiers de cache détournés, fichiers au nom trompeur (.well-known/, tmp/.sess_*), ou endpoints cachés derrière des extensions inoffensives (.ico, .png) mais interprétés côté serveur suite à une mauvaise config.

Indicateurs de compromission (IOC) et techniques de détection pragmatiques

Commencez par accepter une réalité : PrestaShop n’a pas, nativement, d’outillage sérieux de File Integrity Monitoring (FIM). Si vous ne comparez pas vos fichiers à une référence « known good », vous travaillez à l’aveugle. L’approche la plus robuste reste : reconstruire l’arborescence applicative depuis un artefact de build (CI) et traiter la prod comme un runtime jetable. Si vous n’y êtes pas encore, au minimum : checksum quotidien sur modules/, themes/, override/, controllers/, et audit des timestamps.

IOC fréquents à chercher (rapide à prioriser)

Zone	IOC (indices concrets)	Pourquoi c’est suspect
Fichiers	nouveaux `.php` dans `themes/` ou `themes//assets/` ; endpoints “asset” (`.js.php`)	les thèmes devraient servir du contenu statique, pas du PHP
Config	présence de `.user.ini` ; modifications récentes de `php.ini`/pool PHP-FPM	vecteur classique d’injection globale (`auto_prepend_file`)
PrestaShop	hook ajouté/altéré dans un module ; override récent	point d’exécution automatique sur pages sensibles
Logs	pics de 302/200 sur endpoints bizarres ; POST anormaux vers `/modules/.../ajax.php`	les droppers utilisent souvent des endpoints déjà “autorisés”
Réseau	nouvelles destinations sortantes, DNS atypiques, webhooks	un infostealer doit exfiltrer (ou recevoir des ordres)

Sur un serveur Linux (Nginx/Apache + PHP-FPM), première passe rapide (sans outils externes) :

# 1) Fichiers modifiés récemment dans l'app
find /var/www/boutique -type f -mtime -7 -not -path '*/var/cache/*' -ls

# 2) Motifs d'obfuscation courants (à trier, pas à supprimer en masse)
grep -R --line-number --binary-files=without-match \
  -E "base64_decode\(|gzinflate\(|str_rot13\(|eval\(|assert\(|preg_replace\(.*\/e" \
  /var/www/boutique

# 3) Présence de .user.ini (souvent absent en prod durcie)
find /var/www/boutique -name '.user.ini' -ls

Ajoutez deux vérifications simples, souvent oubliées, qui attrapent des persistances “silencieuses” :

# 4) Cron (utilisateur + système)
crontab -l
sudo ls -la /etc/cron.* /etc/crontab

# 5) Timers systemd (si serveur moderne)
systemctl list-timers --all | head -n 50

Ce n’est pas « de la forensic », mais ça attrape une part significative des infections opportunistes. Ensuite, corrélez avec les logs : var/logs/prod.log (Symfony), logs web (access.log, error.log), logs PHP-FPM, et surtout les traces de back-office (connexions admin, créations d’employés, changements de modules). Pour industrialiser, vous avez intérêt à instrumenter l’alerting (voir : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail et Surveillance PrestaShop : tableau de bord, seuils et réduction des fausses alertes).

Enfin, la différence entre un skimmer « client-side » et un skimmer « server-assisted », c’est l’egress. Un infostealer a besoin de sortir. Mesurez et bloquez : flux sortants HTTP(S) depuis le pool PHP-FPM, requêtes DNS anormales, connexions vers des ASNs inattendus. Dans un setup propre, le serveur web n’a généralement pas besoin d’initier des connexions arbitraires (hors APIs explicitement listées : PSP, ERP, SMS, transporteurs).

Une méthode pragmatique (et très “ops-friendly”) consiste à maintenir une liste d’egress autorisés :

domaines et IP de votre PSP (ex. endpoints API),
endpoints de transporteurs,
ERP/WMS/TMS,
SMTP transactionnel (si vous n’avez pas de relais interne),
services de scoring/anti-fraude (si utilisés).

Tout le reste : blocage ou alerte. Si vous ne pouvez pas mettre une politique egress (iptables/nftables, security groups, eBPF), au moins alertez sur les connexions sortantes nouvelles (par destination + volume + fréquence).

Durcissement serveur et PHP pour casser l’exécution et l’exfiltration

Le levier le plus rentable n’est pas « encore un plugin sécurité ». C’est de retirer les droits d’écriture au runtime sur le code. Sur PrestaShop, vous pouvez (et devriez) séparer :

répertoires écrits par PrestaShop : var/, img/, download/, upload/ (et éventuellement modules/ seulement si vous installez depuis le BO — ce qui est déjà discutable) ;
répertoires read-only en prod : classes/, controllers/, override/, themes/, vendor/, src/.

Deux repères pratiques pour éviter le “read-only théorique” :

si votre serveur met à jour des modules via BO, vous redonnez mécaniquement au PHP la capacité de déposer/altérer du code (donc de persister) ;
si un module doit écrire dans son répertoire (mauvaise pratique mais fréquent), forcez-le à écrire dans var/ (logs, caches, exports) et bloquez l’écriture dans modules/ par défaut.

Si votre process de déploiement impose d’écrire en prod (FTP, modifications directes), vous entretenez la compromission : un attaquant réutilise le même canal. Une approche réaliste : build en CI, déploiement atomique (symlink current), et permissions strictes. À ce sujet, les checklists de migration aident à cadrer le risque (voir : Migration PrestaShop 9 : sécurité, tests et plan de rollback et Migration PrestaShop 9 : checklist complète sécurité, SEO, performance).

Durcissement PHP (à adapter, attention aux régressions fonctionnelles) :

désactiver la configuration par répertoire si possible : user_ini.filename= (vide) pour neutraliser .user.ini ;
réduire l’arsenal d’exécution : disable_functions = exec,passthru,shell_exec,system,proc_open,popen (et tester vos modules) ;
verrouiller les chemins : open_basedir (utile mais casse facilement des intégrations ; à piloter pool par pool) ;
interdire l’inclusion distante : allow_url_include=0 (indispensable), allow_url_fopen=0 si vous pouvez ;
isoler PHP-FPM par vhost : un pool par site, user dédié, listen.owner/group, et pas de mutualisation laxiste.

Pour les webskimmers qui injectent du JavaScript, les headers de sécurité restent un filet utile… à condition d’être réaliste. Une CSP stricte (script-src 'self' 'nonce-…') est difficile sur des thèmes PrestaShop bourrés d’inline scripts et de modules qui injectent du JS à la volée. Mais même une CSP « transitoire » (report-only + blocage progressif des domaines tiers) réduit les exfiltrations triviales : si votre checkout n’a aucune raison de contacter example-cdn.bad, vous voulez le voir immédiatement dans les rapports CSP. Pour le concret : HTTP Security Headers en PHP : guide CSP, HSTS, X-Frame-Options.

À l’entrée, un WAF bien réglé et du ban automatisé réduisent fortement les infections opportunistes (bruteforce BO, scans, payloads connus), mais vous devez gérer les faux positifs sur le checkout. Voir : WAF PrestaShop : réduire les faux positifs et sécuriser le checkout et, côté blocage d’abus, PrestaShop sécurité : bloquer la navigation à facettes via fail2ban.

Enfin, côté hygiène “référentiel”, un bon complément (neutre et applicable à l’écosystème FR) est le Guide d’hygiène informatique de l’ANSSI, utile pour structurer mots de passe, MFA, sauvegardes et cloisonnement : https://www.ssi.gouv.fr/guide/guide-dhygiene-informatique/

Sécuriser la supply chain : modules, thèmes, overrides et CI/CD

En 2026, le vecteur n°1 sur PrestaShop reste la supply chain : modules premium récupérés hors circuit, zip « patché » par un prestataire, thème legacy dont la chaîne npm est morte, fork GitHub non vérifié. Le cœur de PrestaShop ne vous protège pas : il n’impose pas de signature des modules, il n’a pas de sandbox d’exécution, et il laisse beaucoup d’extensions faire du PHP arbitraire (donc potentiellement du réseau sortant). La conséquence : votre sécurité dépend directement de vos règles de provenance.

Concrètement, vous voulez une pipeline qui refuse le flou :

sources contrôlées (dépôts, tags, releases) et vérification anti-forks ;
génération d’un SBOM et contrôle de dépendances (Composer + éventuellement npm/yarn côté thème) ;
build reproductible, artefacts immuables ;
validation statique minimale (lint, PHPStan/Psalm, recherche d’obfuscation) ;
interdiction d’installation de modules « en prod » depuis le BO.

Pour cadrer ces sujets sans réinventer : CI PrestaShop : provenance, SBOM et validation automatique des modules et PrestaShop GitHub : dépôts officiels, vérification et sécurité anti-forks.

Deux contrôles simples qui évitent beaucoup de “mauvaises surprises” lors d’un audit :

inventaire des modules réellement actifs (et suppression du reste) : moins de code = moins de surface d’attaque ;
revue des permissions réseau : un module de FAQ ou de “slider” n’a aucune raison d’émettre des POST vers l’extérieur.

Un point souvent négligé : les secrets d’intégration sont dans la même zone de risque que les cartes. Une boutique qui se fait voler une clé API d’ERP/WMS/TMS perd plus que des commandes : elle perd la confiance de toute la chaîne. Si vous exposez des endpoints, faites l’hygiène minimum : rotation, scopes, rate limiting, stockage chiffré, et logs d’accès. Voir : API : sécuriser apikey, limiter le débit et renforcer la conformité et, pour les architectures d’échange, Portail client : intégration ERP/WMS/TMS via API, fichiers et webhooks.

Enfin, gardez en tête un effet de bord : un webskimmer « propre » ajoute souvent une requête réseau (ou une exfil DNS) et quelques kilo-octets de JS. Ça peut se voir dans les waterfalls, dans une dégradation de TTFB/INP si l’injection est mal faite, et parfois dans une hausse d’erreurs JS. Même si la perf n’est pas votre outil de sécurité, une baseline CWV est un détecteur d’anomalie non négligeable : un “petit” changement de scripts en checkout peut être le premier signal exploitable. (voir : PrestaShop performance : optimiser gros catalogues et Core Web Vitals).

Réponse à incident : containment, éradication, preuves et obligations

Quand vous suspectez un webskimmer/infostealer, le piège est de « nettoyer vite » en prod et de perdre la trace de la persistance. La définition NIST rappelle pourquoi :

« A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. » — NIST SP 800-61 Rev.2, Computer Security Incident Handling Guide : https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

Traitez ça comme un incident : préserver, contenir, éradiquer, restaurer.

Containment (ordre de priorité, à adapter) : isolez l’admin (VPN, allowlist IP), mettez le checkout en maintenance si vous avez le moindre doute sur la capture de cartes, bloquez l’egress non indispensable, et geler l’état (snapshot VM/LVM/ZFS, copie des logs, export des crons, liste des processus). Ne vous contentez pas de « supprimer le fichier suspect » : si une persistance via .user.ini/cron/webshell existe, elle va reposer le payload.

Pour éviter les erreurs “classiques” pendant le containment, vous pouvez vous imposer une règle simple : tout ce qui est fait doit être horodaté et reproductible (commande, personne, résultat). Même sans équipe SOC, ce journal vous sauve du flou quand il faut expliquer la chronologie à un PSP, à un hébergeur, ou à une autorité.

Éradication : reconstruisez depuis une source propre. En pratique, cela ressemble souvent à un redeploy complet (core + vendor + thèmes + modules) et à une restauration sélective des seuls répertoires de contenu (img/, uploads) après scan. Changez tous les secrets (DB, back-office, comptes SFTP/SSH, API PSP, webservice keys, SMTP), et vérifiez les accès. Pour industrialiser et réduire le temps d’exposition, une approche de maintenance infogérée et de sauvegardes chiffrées est plus fiable que les « scripts maison » non testés (voir : Maintenance PrestaShop : managed services, sécurité serveur, sauvegardes chiffrées).

Restauration et post-mortem : réactivez progressivement, avec monitoring renforcé et WAF en mode observation si nécessaire.

Si vous traitez des paiements, n’improvisez pas la partie conformité : votre objectif est de réduire l’exposition (idéalement via redirection/hosted fields PSP, tokenisation) et de vous aligner sur les exigences PCI-DSS (référentiel : https://www.pcisecuritystandards.org/).
Côté RGPD, si des données personnelles sont exfiltrées, vous devez documenter les faits, évaluer le risque, et déclencher vos procédures internes (DPO, registre, notifications si nécessaire). En France, la CNIL met à disposition une page dédiée à la notification des violations de données (utile pour cadrer le “quoi” et le “quand”) : https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles

L’important ici n’est pas le discours : c’est la traçabilité des décisions, l’horodatage, et la capacité à prouver ce que vous avez fait.

Pour finir, une check-list opérationnelle « anti-récidive » (à transformer en tickets) : patching régulier (Sécurité PrestaShop : mises à jour, SSL et durcissement .htaccess), politique egress, runtime en lecture seule, CI avec SBOM, interdiction d’installation de modules en prod, rotation des secrets, et alerting sur modifications de fichiers.

Si vous ne pouvez appliquer que deux mesures : (1) retirer l’écriture du code au PHP-FPM et (2) contrôler strictement la provenance des modules. Le reste découle de ces deux points.