Knowledge Base Guide

Sécurisation PrestaShop : La checklist complète

Guide complet de sécurité pour PrestaShop — durcissement serveur, protection admin, audit des modules, sécurité base de données et réponse aux incidents.

Sécurisation de PrestaShop : la checklist complète

Chaque semaine, des milliers de boutiques PrestaShop sont compromises. Les propriétaires le découvrent lorsque Google signale leur site, lorsque des clients signalent des cartes volées, ou lorsque la page d’accueil redirige vers du spam. Les dégâts sont réels : perte de chiffre d’affaires, confiance détruite, responsabilité RGPD et des semaines de remise en état.

Ce guide est le fruit d’années de nettoyage de boutiques piratées. Chaque recommandation répond à une vulnérabilité réelle que nous avons vue exploitée en production. Suivez-le du début à la fin.

1. Pourquoi les boutiques PrestaShop se font pirater

Injection SQL dans les modules tiers

C’est le vecteur d’attaque numéro un, et de loin. Les modules de développeurs inexperimentés passent souvent les données utilisateur directement dans les requêtes SQL. Un attaquant envoie une requête spécialement conçue au front controller d’un module et extrait l’intégralité de votre base de données. La vulnérabilité ne se trouve presque jamais dans le cœur de PrestaShop — elle est dans les modules.

Attaque par force brute du panneau d’administration

PrestaShop ne dispose d’aucune limitation de débit intégrée. Un attaquant qui connaît le nom de votre répertoire d’administration peut tester des milliers de combinaisons de mots de passe par minute. Tout compte utilisant admin123 ou le nom de l’entreprise sera craqué en quelques minutes.

Vulnérabilités d’upload de fichiers

Certains modules permettent l’upload de fichiers sans validation adéquate. Un attaquant envoie un shell PHP déguisé en image, y accède via le navigateur et obtient le contrôle total du serveur.

PHP et logiciels obsolètes

Les versions PHP en fin de vie présentent des vulnérabilités documentées publiquement avec des exploits fonctionnels. Il en va de même pour les versions obsolètes de PrestaShop, Apache et MySQL.

Fichiers de configuration exposés

Des serveurs mal configurés servent les fichiers .env, les répertoires .git et les fichiers de configuration YAML à quiconque les demande — révélant les identifiants de base de données et les clés de chiffrement.

Réalité : La plupart des propriétaires pensent « ma boutique est trop petite pour être ciblée ». Les scanners automatisés ne se soucient pas de la taille. Ils scannent chaque adresse IP sur Internet. Si vous utilisez PrestaShop, vous êtes une cible.

2. Sécurité au niveau du serveur

Version et configuration de PHP

Utilisez la version PHP la plus récente que votre PrestaShop prend en charge — PHP 8.1+ pour PS 8.x, PHP 8.1-8.4 pour PS 9.x. N’utilisez jamais une version en fin de vie.

Durcissement clé de php.ini :

disable_functions = exec,passthru,shell_exec,system,proc_open,popen
expose_php = Off
allow_url_include = Off
display_errors = Off
log_errors = On
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1
session.cookie_samesite = Lax
open_basedir = /var/www/html:/tmp:/usr/share/php
Remarque : Certains modules ont besoin de exec() pour le traitement d’images ou la génération de PDF. Si un module ne fonctionne plus, réactivez uniquement la fonction spécifique dont il a besoin.

Permissions de fichiers

  • Répertoires : 755 — lecture/écriture/exécution pour le propriétaire, lecture/exécution pour les autres
  • Fichiers : 644 — lecture/écriture pour le propriétaire, lecture seule pour les autres
  • Fichiers de configuration : 400 — app/config/parameters.php doit être en lecture seule pour le propriétaire
chown -R www-data:www-data /var/www/html/prestashop
find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chmod 400 /var/www/html/prestashop/app/config/parameters.php

# Writable directories PrestaShop needs
chmod -R 775 /var/www/html/prestashop/var/cache
chmod -R 775 /var/www/html/prestashop/var/logs
chmod -R 775 /var/www/html/prestashop/img
chmod -R 775 /var/www/html/prestashop/upload
chmod -R 775 /var/www/html/prestashop/download

Ne mettez jamais quoi que ce soit en 777. Si un tutoriel vous dit de faire chmod 777, trouvez un meilleur tutoriel.

Configuration SSL/TLS

Activez SSL dans PrestaShop (Paramètres de la boutique > Général), puis ajoutez les en-têtes HSTS :

# Apache .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Nginx
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$server_name$request_uri;
}
server {
    listen 443 ssl http2;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

Désactiver le listing des répertoires et renforcer le .htaccess

Ajoutez ces règles à votre .htaccess racine :

Options -Indexes

# Block sensitive file types
<FilesMatch "\.(env|yml|yaml|log|sql|bak|old|orig|save|swp|dist|config|ini|phps)$">
    Require all denied
</FilesMatch>

# Block hidden files and directories (.git, .env, etc.)
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule (^\.|/\.) - [F]
</IfModule>

# Block composer files
<FilesMatch "^(composer\.json|composer\.lock)$">
    Require all denied
</FilesMatch>

# Block config, vendor, and log directories
<IfModule mod_rewrite.c>
    RewriteRule ^config/ - [F]
    RewriteRule ^vendor/ - [F]
    RewriteRule ^var/logs/ - [F]
    RewriteRule ^app/config/ - [F]
</IfModule>

# Block PHP execution in upload directories
<Directory "/var/www/html/prestashop/upload">
    <FilesMatch "\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

<Directory "/var/www/html/prestashop/img">
    <FilesMatch "\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

Équivalent Nginx :

location ~* \.(env|yml|yaml|log|sql|bak|old|swp|dist|config|ini)$ { deny all; return 404; }
location ~ /\. { deny all; return 404; }
location ~* ^/(upload|img|download)/.*\.php$ { deny all; return 404; }
location ~* ^/(config|vendor|var/logs|app/config)/ { deny all; return 404; }
autoindex off;
Testez : Après avoir ajouté ces règles, essayez d’accéder à https://votreboutique.com/.env et https://votreboutique.com/app/config/parameters.php dans votre navigateur. Vous devriez obtenir une erreur 403 ou 404 — jamais le contenu réel.

3. Sécurité de l’administration PrestaShop

Renommer le répertoire d’administration

PrestaShop génère un nom de répertoire d’administration aléatoire lors de l’installation. Ne le renommez jamais en admin, backoffice ou panel. S’il est prévisible, changez-le :

mv /var/www/html/prestashop/admin /var/www/html/prestashop/admin-x7k9m2p4
rm -rf /var/www/html/prestashop/var/cache/*

Utilisez au moins 10 caractères aléatoires. Ajoutez l’URL à vos favoris — il n’est pas nécessaire de la retenir.

Mots de passe robustes et 2FA

Chaque compte administrateur doit utiliser un mot de passe unique d’au moins 16 caractères généré par un gestionnaire de mots de passe. Aucune exception.

Activez l’authentification à deux facteurs pour tous les comptes (Paramètres avancés > Administration). PrestaShop 1.7.6+ prend en charge Google Authenticator nativement. Cette seule mesure bloque la grande majorité des attaques par force brute.

Limiter l’accès à l’administration par IP

Si votre équipe travaille depuis des adresses IP fixes, restreignez l’accès à l’administration en conséquence :

# .htaccess inside admin directory
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
    RewriteCond %{REMOTE_ADDR} !^198\.51\.100\.20$
    RewriteRule .* - [F,L]
</IfModule>

Si vous utilisez un VPN, restreignez l’accès à l’adresse IP du VPN — les employés travaillent de n’importe où tout en restant restreints par IP.

Désactiver les comptes employés inutiles

Auditez régulièrement les comptes employés (Paramètres avancés > Équipe > Employés) :

  • Supprimez les comptes des anciens employés et prestataires
  • Supprimez les comptes de test créés lors de l’installation initiale
  • Assurez-vous que chaque employé dispose du profil minimum nécessaire — le personnel d’entrepôt n’a pas besoin du profil SuperAdmin

Surveillance des connexions à l’administration

Mettez en place fail2ban pour la protection contre les attaques par force brute :

# /etc/fail2ban/filter.d/prestashop-admin.conf
[Definition]
failregex = ^<HOST> -.*"POST .*/admin.*/index\.php\?controller=AdminLogin.*" (200|302)

# /etc/fail2ban/jail.d/prestashop.conf
[prestashop-admin]
enabled = true
filter = prestashop-admin
logpath = /var/log/apache2/access.log
maxretry = 5
findtime = 600
bantime = 3600

4. Sécurité des modules

Les modules constituent la plus grande surface d’attaque de toute installation PrestaShop. Traitez chaque module comme un risque potentiel tant que le contraire n’est pas prouvé.

N’installez que des modules provenant de sources fiables

Sources sûres : la marketplace PrestaShop Addons, les développeurs établis avec un historique reconnu, et les modules open source bien maintenus sur GitHub.

N’installez jamais de modules provenant de sites « nullés » ou de « téléchargement gratuit », de développeurs inconnus ou de messages de forums aléatoires.

Attention : Les modules nullés (piratés) sont le moyen le plus rapide de se faire pirater. Les attaquants injectent des portes dérobées dans des modules légitimes et les distribuent gratuitement. La porte dérobée leur donne le contrôle de chaque boutique qui l’installe. Nous avons vu cela des centaines de fois. Il n’y a aucune exception.

Auditer le code des modules

Avant d’installer un module, recherchez ces signaux d’alerte :

# Dangerous — arbitrary code execution
eval($variable)
eval(base64_decode($something))
assert($user_input)

# Dangerous — remote code loading
file_get_contents('http://external-domain.com/...')
include('http://...')

# Dangerous — unsanitized SQL
"SELECT * FROM ps_table WHERE id = " . $_GET['id']
Db::getInstance()->execute("... " . $_POST['value'] . " ...")

Le code sécurisé utilise des requêtes paramétrées et les méthodes de validation de PrestaShop :

// SAFE: Cast to integer, use pSQL()
$id = (int)Tools::getValue('id');
$name = pSQL(Tools::getValue('name'));

Maintenez les modules à jour

  • Vérifiez les mises à jour au moins une fois par semaine
  • Abonnez-vous aux bulletins de sécurité des développeurs
  • Suivez les avis de sécurité Friends of Presta pour les CVE des modules PrestaShop
  • Faites toujours une sauvegarde avant de mettre à jour

Supprimez complètement les modules inutilisés

Désactiver un module ne suffit pas. Les fichiers d’un module désactivé restent présents sur votre serveur et ses front controllers restent accessibles via une URL directe. S’il présente une vulnérabilité, la désactivation n’offre aucune protection.

# Uninstall via Back Office, then delete the files
rm -rf /var/www/html/prestashop/modules/unused_module

Parcourez votre liste de modules maintenant. Si vous avez installé quelque chose pour tester il y a six mois — supprimez-le. Chaque module inutilisé représente une surface d’attaque inutile.

Auditer les permissions des modules

find /var/www/html/prestashop/modules -type d -exec chmod 755 {} \;
find /var/www/html/prestashop/modules -type f -exec chmod 644 {} \;

5. Sécurité de la base de données

N’utilisez jamais root pour l’application

Créez un utilisateur dédié avec des permissions minimales :

CREATE USER 'prestashop_user'@'localhost' IDENTIFIED BY 'long-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
      CREATE TEMPORARY TABLES, LOCK TABLES
      ON prestashop_db.* TO 'prestashop_user'@'localhost';
FLUSH PRIVILEGES;

Si un attaquant exploite une injection SQL, un utilisateur aux droits limités restreint les dégâts. L’utilisateur root peut accéder aux autres bases de données, lire les fichiers du serveur et exécuter des commandes système.

Sauvegardes régulières

# Crontab entries
# Database backup — daily at 3 AM
0 3 * * * mysqldump -u backup_user -p'password' prestashop_db | gzip > /backups/db/ps_$(date +\%Y\%m\%d).sql.gz

# File backup — daily at 3:30 AM
30 3 * * * tar -czf /backups/files/ps_files_$(date +\%Y\%m\%d).tar.gz /var/www/html/prestashop/

# Cleanup backups older than 30 days
0 4 * * * find /backups/ -name "*.gz" -mtime +30 -delete

Règles essentielles :

  • Stockez les sauvegardes hors du serveur — si le serveur est compromis, les sauvegardes locales le sont aussi
  • Testez vos sauvegardes mensuellement — restaurez dans un environnement de test et vérifiez que le site fonctionne
  • Chiffrez avant le transfert hors site — les dumps contiennent des données personnelles de clients
  • Conservez plus de 30 jours de sauvegardes quotidiennes — certaines compromissions ne sont pas découvertes immédiatement

Sécuriser phpMyAdmin (ou le supprimer)

L’option la plus sûre : n’installez pas phpMyAdmin en production. Utilisez plutôt des tunnels SSH :

# From your LOCAL machine
ssh -L 3307:localhost:3306 user@yourserver.com
# Then connect your local MySQL client to localhost:3307

Si vous devez utiliser phpMyAdmin : restreignez l’accès par IP, utilisez un chemin d’URL aléatoire, activez l’authentification HTTP Basic et désactivez la connexion root :

$cfg['Servers'][$i]['AllowRoot'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

6. Surveillance et détection

Surveillance de l’intégrité des fichiers

Les attaquants modifient des fichiers — en injectant des portes dérobées, en ajoutant des shells dans les répertoires d’upload ou en altérant le .htaccess. Détectez les modifications avec une tâche cron quotidienne :

#!/bin/bash
# /usr/local/bin/prestashop-integrity-check.sh
SHOP_DIR="/var/www/html/prestashop"
BASELINE="/var/backups/prestashop-file-hashes.txt"
CURRENT="/tmp/prestashop-file-hashes-current.txt"
ALERT_EMAIL="admin@yourdomain.com"

find "$SHOP_DIR" -type f \
    -not -path "*/var/cache/*" \
    -not -path "*/var/logs/*" \
    -not -path "*/img/p/*" \
    -not -path "*/img/c/*" \
    -exec md5sum {} \; | sort > "$CURRENT"

if [ -f "$BASELINE" ]; then
    DIFF=$(diff "$BASELINE" "$CURRENT")
    if [ -n "$DIFF" ]; then
        echo "$DIFF" | mail -s "ALERT: PrestaShop files modified" "$ALERT_EMAIL"
    fi
fi

Générez la référence après un déploiement propre, puis ce script vous envoie un e-mail chaque fois que des fichiers sont modifiés de manière inattendue.

Surveillance des logs

Analysez les logs d’accès à la recherche de schémas d’attaque :

# SQL injection attempts
grep -iE "(union\s+select|or\s+1=1|information_schema)" /var/log/apache2/access.log

# File inclusion attempts
grep -iE "(etc/passwd|\.\.\/\.\.\/)" /var/log/apache2/access.log

# Direct module file access (potential exploit attempts)
grep -E "modules/.*/ajax|modules/.*/api" /var/log/apache2/access.log

Mettez en place des résumés quotidiens des logs via cron, ou alimentez les logs dans un système centralisé comme Graylog ou Papertrail pour des alertes en temps réel.

Surveillance de la disponibilité

  • Utilisez UptimeRobot, Hetrix Tools ou Uptime Kuma en auto-hébergé
  • Surveillez à la fois la page d’accueil et la page de commande
  • Vérifiez le contenu spécifique de la page, pas seulement le code HTTP 200 — une page défacée renvoie aussi un code 200
  • Vérifiez toutes les 1 à 5 minutes avec des alertes par e-mail, SMS ou Slack

Alertes de connexion à l’administration

Soyez notifié de chaque connexion à l’administration grâce à un simple hook :

public function hookActionAdminLoginControllerLoginAfter($params)
{
    $employee = $params['employee'];
    $ip = Tools::getRemoteAddr();

    Mail::Send(
        (int)Configuration::get('PS_LANG_DEFAULT'),
        'alert_admin_login',
        "Admin Login: {$employee->email} from {$ip}",
        ['{body}' => "Employee: {$employee->email}\nIP: {$ip}\nTime: " . date('Y-m-d H:i:s')],
        'security@yourdomain.com',
        'Security Alert'
    );
}

7. Que faire si vous avez été piraté

Réponse immédiate (les 30 premières minutes)

  • Ne supprimez encore rien — vous avez besoin des fichiers pour l’analyse forensique
  • Mettez la boutique hors ligne avec une page de maintenance pour stopper les dégâts en cours
  • Changez TOUS les mots de passe : SSH, FTP, base de données, comptes administrateurs, panneau d’hébergement, clés de passerelle de paiement
  • Sauvegardez l’état compromis — étiquetez-le « compromis » pour une analyse ultérieure
  • Prévenez votre processeur de paiement si vous gérez les paiements directement
# Quick maintenance mode
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\.IP\.ADDRESS$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule .* /maintenance.html [R=503,L]

Trouver la porte dérobée

Les attaquants laissent toujours des portes dérobées pour revenir. Nettoyer le piratage visible sans trouver la porte dérobée signifie une re-compromission en quelques jours.

# Search for backdoor patterns
grep -rn "eval(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"
grep -rn "base64_decode" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"
grep -rn "shell_exec\|passthru\|system(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"

# Find recently modified PHP files
find /var/www/html/prestashop/ -name "*.php" -mtime -7 -not -path "*/cache/*"

# Find PHP files in directories where they should not exist
find /var/www/html/prestashop/img/ -name "*.php"
find /var/www/html/prestashop/upload/ -name "*.php"

# Check for obfuscated code (very long single lines)
find /var/www/html/prestashop/ -name "*.php" -exec awk 'NR==1 && length>5000' {} +

Vérifiez également la base de données :

SELECT id_cms, meta_title FROM ps_cms_lang WHERE content LIKE '%<?php%' OR content LIKE '%eval(%';
SELECT * FROM ps_employee ORDER BY date_add DESC LIMIT 10;

Processus de récupération

  1. Déterminez le point d’entrée à partir des logs d’accès — recherchez les requêtes POST inhabituelles vers les controllers de modules aux alentours du moment de la compromission
  2. Restaurez à partir d’une sauvegarde propre si disponible. Vérifiez que la sauvegarde est antérieure à la compromission.
  3. Si aucune sauvegarde propre n’existe : remplacez tous les fichiers du cœur par un téléchargement neuf de votre version exacte de PS, réinstallez tous les modules à partir des sources originales, ne conservez que votre thème et le répertoire img/ (analysez-les minutieusement)
  4. Analysez la base de données à la recherche de contenu injecté dans ps_configuration, ps_cms_lang et ps_meta_lang
  5. Mettez tout à jour — cœur, modules, PHP, MySQL, système d’exploitation

Prévention après le nettoyage

  • Supprimez ou corrigez la vulnérabilité spécifique qui a été exploitée
  • Surveillez intensivement pendant le premier mois — les attaquants essaient souvent de revenir
  • Envisagez un WAF (niveau gratuit de Cloudflare, Sucuri ou ModSecurity)
  • Si des données de paiement ont potentiellement été compromises, consultez un avocat concernant les obligations de notification RGPD (délai de 72 heures)
Vérité difficile : Si vous ne pouvez pas déterminer comment l’attaquant est entré, partez du principe qu’il reviendra. Un audit de sécurité professionnel coûte une fraction du prix d’une deuxième violation.

8. Checklist de sécurité

Imprimez cette liste et parcourez-la. Chaque élément non coché est un point d’entrée potentiel.

Serveur et PHP

  • La version PHP est à jour et supportée
  • Les fonctions PHP dangereuses sont désactivées
  • expose_php = Off
  • display_errors = Off en production
  • allow_url_include = Off
  • Cookies de session : HttpOnly, Secure, SameSite
  • open_basedir configuré
  • Système d’exploitation, MySQL et serveur web à jour
  • Authentification SSH par clé activée, authentification par mot de passe désactivée
  • Pare-feu configuré (seuls les ports nécessaires sont ouverts)

Système de fichiers

  • Répertoires : 755, Fichiers : 644
  • parameters.php : 400
  • Aucun fichier en 777
  • Exécution PHP bloquée dans upload/, img/, download/
  • Listing des répertoires désactivé
  • Fichiers .env, .git, YAML et de configuration bloqués depuis le web
  • vendor/ et var/logs/ bloqués depuis le web

SSL et HTTPS

  • Certificat SSL valide avec renouvellement automatique
  • Redirection HTTP vers HTTPS en place
  • En-tête HSTS configuré
  • SSL activé dans PrestaShop (toutes les pages)
  • Aucun avertissement de contenu mixte

Panneau d’administration

  • Le répertoire d’administration a un nom aléatoire
  • Tous les mots de passe font 16+ caractères et proviennent d’un gestionnaire de mots de passe
  • 2FA activée pour tous les comptes
  • Accès à l’administration restreint par IP (si possible)
  • Comptes inutiles supprimés
  • Chaque employé dispose des permissions minimales nécessaires
  • Protection contre la force brute (fail2ban ou équivalent)

Modules

  • Tous les modules proviennent de sources fiables
  • Aucun module nullé/piraté
  • Tous les modules sont à jour
  • Les modules inutilisés sont supprimés (pas seulement désactivés)
  • Le code des modules a été audité pour eval() et les requêtes SQL non assainies
  • Abonné aux avis de sécurité

Base de données

  • Utilisateur de base de données dédié (pas root)
  • Permissions minimales accordées
  • Mot de passe de base de données robuste (20+ caractères)
  • MySQL lié uniquement à localhost
  • phpMyAdmin supprimé ou restreint par IP
  • Préfixe des tables changé depuis la valeur par défaut ps_

Sauvegardes

  • Sauvegardes automatiques quotidiennes de la base de données
  • Sauvegardes automatiques quotidiennes des fichiers
  • Sauvegardes stockées hors du serveur
  • Sauvegardes chiffrées avant le transfert
  • Conservation de plus de 30 jours
  • Restauration testée au cours des 30 derniers jours

Surveillance

  • Surveillance de l’intégrité des fichiers active
  • Logs d’accès surveillés pour les schémas d’attaque
  • Surveillance de la disponibilité avec vérification du contenu
  • Alertes de connexion à l’administration activées
  • En-têtes de sécurité en place

Préparation aux incidents

  • Plan de réponse aux incidents documenté
  • Contacts de l’hébergeur et du processeur de paiement accessibles
  • Processus de notification RGPD documenté
  • Page de maintenance prête à déployer
  • Tous les mots de passe critiques dans un gestionnaire de mots de passe

La sécurité est un processus continu, pas une configuration ponctuelle. Planifiez une revue trimestrielle. Le temps que vous investissez maintenant est insignifiant comparé au coût de la récupération après une violation. Commencez par les éléments à fort impact : mettez tout à jour, activez la 2FA, supprimez les modules inutilisés et configurez les sauvegardes. Puis travaillez sur le reste.

Vos clients vous confient leurs données personnelles. Honorez cette confiance.

More guides available

Browse our knowledge base for more practical PrestaShop tutorials, or reach out if you need help.

Browse Knowledge Base Contact Us
Back to top