Sécurité PrestaShop : protéger sa boutique contre les failles courantes

Publié le — PrestaShop

Une boutique PrestaShop manipule des données sensibles : informations clients, historiques de commandes, moyens de paiement. En 2025, le coût moyen d'une violation de données dans le e-commerce atteint 3,54 millions de dollars (Verizon DBIR 2025). Les attaques ciblent en priorité les modules tiers vulnérables, les versions non mises à jour et les configurations serveur par défaut. Ce guide couvre les failles courantes, les outils d'audit et les bonnes pratiques de durcissement.

Les failles courantes sur PrestaShop

Injection SQL

L'injection SQL est la faille la plus critique sur PrestaShop. Un attaquant injecte du code SQL malveillant dans un champ de formulaire ou un paramètre d'URL pour accéder à la base de données, voler des informations clients ou modifier des commandes.

PrestaShop inclut la fonction pSQL() qui échappe les entrées utilisateur. Mais cette protection ne s'applique que si le développeur l'utilise systématiquement. Les modules tiers qui construisent des requêtes SQL sans pSQL() ou sans requêtes préparées sont la première source de failles.

Des failles d'injection SQL sont régulièrement découvertes, notamment dans les modules tiers qui construisent des requêtes sans utiliser pSQL() ou les requêtes préparées. Consultez les Friends of Presta Security Advisories pour les alertes en cours.

Cross-Site Scripting (XSS)

Le XSS permet à un attaquant d'injecter du JavaScript malveillant qui s'exécute dans le navigateur des visiteurs. Les attaques XSS stockées sont particulièrement dangereuses car le code malveillant est enregistré en base de données et s'exécute pour chaque visiteur.

  • PrestaShop bloque nativement les XSS de catégorie 1 (<script>) via strip_tags() dans son ORM legacy.
  • Toujours utiliser htmlspecialchars() pour l'affichage des données utilisateur dans les templates.
  • 84 % des organisations ont été exposées à des failles XSS (OWASP).

Digital Skimming (vol de données bancaires)

Le digital skimming consiste à injecter un code malveillant qui remplace les boutons de paiement par de faux formulaires pour capturer les données bancaires des clients. Ce type d'attaque est particulièrement insidieux car invisible pour le marchand — le tunnel d'achat semble fonctionner normalement. Plusieurs cas ont été signalés sur des boutiques PrestaShop non mises à jour.

Brute Force sur le back-office

Les attaques par force brute tentent de deviner le mot de passe admin en testant des milliers de combinaisons. Par défaut, PrestaShop ne limite pas le nombre de tentatives de connexion.

Durcissement du serveur et des headers HTTP

Headers de sécurité

Les headers HTTP sont la première ligne de défense. Ils se configurent dans le .htaccess ou la configuration Apache/Nginx :

  • Content-Security-Policy (CSP) — Restreint les sources de scripts, styles et images autorisées. Une CSP bien configurée réduit les risques XSS de 95 %. Attention : les modules PrestaShop tiers nécessitent souvent unsafe-inline, ce qui affaiblit la protection.
  • Strict-Transport-Security (HSTS) — Force HTTPS et empêche le downgrade vers HTTP. max-age=31536000; includeSubDomains; preload
  • X-Frame-Options — Empêche l'affichage de la boutique dans une iframe (protection clickjacking). SAMEORIGIN
  • X-Content-Type-Options — Empêche le MIME sniffing. nosniff
  • Referrer-Policy — Contrôle les informations envoyées lors de la navigation vers un autre site. same-origin

SSL / HTTPS

L'activation de HTTPS est obligatoire pour toute boutique e-commerce. Dans le back-office PrestaShop : Paramètres avancés → Performance → Activer SSL sur toutes les pages. Configurer aussi les redirections HTTP → HTTPS dans le .htaccess et les cookies en Secure; SameSite=Lax; HttpOnly.

Protection du back-office

  • Renommer le dossier /admin — Le dossier admin a un nom aléatoire par défaut dans PrestaShop, mais vérifiez qu'il n'est pas prévisible.
  • Authentification 2FA — Activer l'authentification à deux facteurs pour tous les comptes admin.
  • Restriction par IP — Limiter l'accès au back-office aux adresses IP autorisées via .htaccess.
  • Mots de passe forts — Minimum 12 caractères, combinant majuscules, minuscules, chiffres et caractères spéciaux.

Préfixe de base de données

Par défaut, PrestaShop utilise le préfixe ps_ pour ses tables. Les attaques automatisées ciblent ce préfixe standard. Le changer lors de l'installation réduit la surface d'attaque, mais c'est une opération délicate sur une boutique existante.

Audit des modules

Les modules tiers sont la première source de vulnérabilités sur PrestaShop. Un seul module non mis à jour peut compromettre toute la boutique. 39 % des CMS compromis étaient obsolètes au moment de l'infection (Sucuri 2023).

Bonnes pratiques modules

  • Mettre à jour systématiquement — Chaque patch de sécurité doit être appliqué dès sa publication. La version seule ne garantit rien : ce sont les mises à jour régulières qui comptent.
  • Vérifier avant d'installer — Consulter les Friends of Presta Security Advisories pour vérifier si le module a des failles connues.
  • Supprimer les modules inutilisés — Un module désactivé mais présent sur le serveur reste une surface d'attaque. Supprimer les fichiers, pas seulement désactiver.
  • Évaluer le sérieux de l'éditeur — Un bon module n'est pas un module sans faille, c'est un module dont l'éditeur corrige les failles rapidement et publie des CVE de manière transparente.

Signes de compromission

  • Fichiers PHP inconnus dans modules/ ou themes/
  • Modifications récentes de fichiers core (vérifier avec git diff ou un outil de monitoring)
  • Comptes admin non créés par vous
  • Redirections vers des sites tiers
  • Faux formulaires de paiement sur le tunnel d'achat
  • Commandes suspectes ou activité inhabituelle en base de données

CVE et transparence

PrestaShop publie les CVE de score CVSS ≥ 7.5 avec un identifiant public. Depuis 2008, plus de 100 CVE ont été répertoriées pour PrestaShop. Ce n'est pas un signe de faiblesse — c'est un signe de maturité. Un écosystème qui publie régulièrement des CVE est un écosystème qui prend la sécurité au sérieux.

Pour suivre les vulnérabilités en temps réel :

Outils d'audit de sécurité

  • PrestaScan Security — Module gratuit open-source qui scanne une boutique PrestaShop 1.7/8/9 à la recherche des vulnérabilités publiées par Friends of Presta.
  • OWASP ZAP — Scanner de sécurité open-source. Proxy d'interception HTTP, scanner passif et actif pour détecter injections SQL, XSS et failles d'authentification.
  • SQLMap — Outil open-source d'automatisation des tests d'injection SQL.
  • Friends of Presta Security — Base de données des CVE spécifiques aux modules PrestaShop, avec alertes et recommandations.
  • Sucuri SiteCheck — Scanner en ligne qui détecte les malwares, les listes noires et les anomalies de sécurité.

Checklist de sécurité PrestaShop

Serveur et infrastructure

  • HTTPS activé sur toutes les pages (SSL/TLS)
  • Headers de sécurité configurés (CSP, HSTS, X-Frame-Options)
  • PHP à jour (8.1+ minimum)
  • MySQL/MariaDB à jour
  • Sauvegardes automatisées (base + fichiers) hors serveur
  • WAF activé (Cloudflare, Sucuri ou ModSecurity)
  • Compression Gzip/Brotli activée

PrestaShop et modules

  • PrestaShop core à jour (dernière version stable)
  • Tous les modules mis à jour
  • Modules inutilisés supprimés (pas seulement désactivés)
  • Vérification Friends of Presta avant installation d'un module
  • Dossier admin avec nom aléatoire
  • 2FA activé sur tous les comptes admin
  • Mots de passe admin ≥ 12 caractères
  • Préfixe BDD différent de ps_

Monitoring

  • Surveillance des fichiers modifiés (alerte en cas de changement inattendu)
  • Logs d'accès admin analysés régulièrement
  • Scan PrestaScan mensuel
  • Veille CVE via Friends of Presta

Questions fréquentes

PrestaShop est-il sécurisé ?

Le core PrestaShop est audité et les failles sont corrigées via des CVE publiques. Le risque vient principalement des modules tiers non mis à jour et des configurations serveur négligées. Un PrestaShop à jour avec des modules maintenus est une plateforme sécurisée.

Comment savoir si ma boutique PrestaShop a été piratée ?

Les signes courants : fichiers PHP inconnus dans les dossiers modules/ ou themes/, comptes admin non créés par vous, redirections vers des sites tiers, faux formulaires de paiement sur le tunnel d'achat, commandes suspectes. Le module PrestaScan peut détecter les vulnérabilités connues.

Les modules PrestaShop gratuits sont-ils dangereux ?

Un module gratuit n'est pas plus dangereux qu'un module payant. Ce qui compte c'est la réputation du développeur, la fréquence des mises à jour et la présence du module dans les advisories de sécurité Friends of Presta. Un module payant mal maintenu est plus risqué qu'un module gratuit régulièrement mis à jour.

Faut-il un WAF pour PrestaShop ?

Un WAF (Web Application Firewall) comme Cloudflare, Sucuri ou ModSecurity peut bloquer jusqu'à 99 % des attaques automatisées (injections SQL, brute force). C'est une couche de protection recommandée, surtout pour les boutiques à fort trafic ou celles qui traitent des paiements.

Top