Sécuriser PrestaShop avant mise en production : checklist complète

Lancer une boutique PrestaShop sans avoir verrouillé les points d'entrée sensibles, c'est laisser la porte du magasin grande ouverte la nuit. Les bots scannent en permanence les URL par défaut (/admin, /phpmyadmin) et exploitent les permissions trop permissives. Voici la checklist de sécurisation que j'applique systématiquement avant chaque mise en production, enrichie pour PrestaShop 8.x.

Renommer le répertoire d'administration

PrestaShop génère un dossier d'administration avec un suffixe aléatoire à l'installation (par exemple admin789xyz). C'est un bon début, mais insuffisant si le nom reste devinable.

Pourquoi c'est critique

Les attaques par force brute ciblent en priorité les chemins prévisibles : /admin, /backoffice, /administration. Un nom aléatoire et long réduit drastiquement la surface d'attaque.

Comment procéder

Renommez le dossier via SSH (jamais via FTP en clair) :

# Sur le serveur, à la racine de PrestaShop
mv admin789xyz k8Tp2mXq9vR4wL

Choisissez une chaîne d'au moins 15 caractères alphanumériques sans signification. Notez ce chemin dans un gestionnaire de mots de passe (Bitwarden, KeePass), jamais dans un fichier texte sur le serveur.

PrestaShop 8.x : Le principe reste identique. Le dossier est toujours renommable sans configuration supplémentaire, PrestaShop détecte automatiquement le nouveau chemin.

Protéger le back-office avec une double authentification HTTP

Même avec un chemin obscur, ajoutez une couche de protection HTTP Basic Auth via .htaccess. Cela crée une double barrière : l'attaquant doit deviner l'URL et posséder les identifiants serveur avant même d'atteindre le formulaire de connexion PrestaShop.

Mise en place sur Apache

Créez un fichier .htpasswd en dehors du répertoire web public :

# Générer le fichier de mots de passe
htpasswd -c /etc/apache2/.htpasswd_prestashop votre_utilisateur

Puis ajoutez un .htaccess dans le dossier d'administration :

AuthType Basic
AuthName "Acces restreint"
AuthUserFile /etc/apache2/.htpasswd_prestashop
Require valid-user

Sur Nginx (PrestaShop 8.x sur VPS moderne)

Si vous utilisez Nginx, la syntaxe diffère :

location /k8Tp2mXq9vR4wL/ {
    auth_basic "Acces restreint";
    auth_basic_user_file /etc/nginx/.htpasswd_prestashop;
    # ... le reste de la configuration PHP-FPM
}

Générez le fichier mot de passe avec la même commande htpasswd ou via openssl passwd.

Verrouiller les permissions de fichiers (exit le 777)

Attribuer un chmod 777 (lecture, écriture, exécution pour tout le monde) à un dossier revient à donner les clés du serveur à n'importe quel processus. C'est la faille la plus fréquente sur les hébergements mutualisés.

Permissions recommandées pour PrestaShop

# Dossiers : lecture + exécution pour le propriétaire et le groupe
find /var/www/prestashop -type d -exec chmod 755 {} \;

# Fichiers : lecture + écriture propriétaire, lecture groupe
find /var/www/prestashop -type f -exec chmod 644 {} \;

# Dossiers nécessitant l'écriture (cache, uploads, logs)
chmod 775 var/cache var/logs img upload download

Propriétaire des fichiers

Assurez-vous que les fichiers appartiennent à l'utilisateur web et non à root :

chown -R www-data:www-data /var/www/prestashop

PrestaShop 8.x : La structure des dossiers a évolué. Le dossier var/ concentre désormais le cache et les logs Symfony. Vérifiez spécifiquement les permissions de var/cache/ et var/logs/.

Masquer l'accès à phpMyAdmin

Par défaut, phpMyAdmin est accessible via http://votre-site.com/phpmyadmin. Des robots scannent systématiquement cette URL pour tenter des injections SQL ou du brute force sur la base de données.

Changer l'alias Apache

Éditez la configuration de phpMyAdmin :

sudo nano /etc/phpmyadmin/apache.conf

Modifiez la directive Alias :

# AVANT (dangereux)
Alias /phpmyadmin /usr/share/phpmyadmin

# APRÈS (sécurisé)
Alias /x7Km9pQr2vBdd /usr/share/phpmyadmin

Redémarrez Apache :

sudo systemctl reload apache2

Alternative recommandée en 2026

Sur un VPS ou serveur dédié, la meilleure pratique consiste à ne pas exposer phpMyAdmin sur le web du tout. Utilisez plutôt un tunnel SSH :

# Depuis votre poste local
ssh -L 8888:localhost:3306 user@votre-serveur.com

# Puis connectez-vous avec un client comme DBeaver ou TablePlus
# sur localhost:8888

Cette approche élimine totalement le vecteur d'attaque web sur la base de données.

Installer et configurer Fail2Ban

Fail2Ban surveille les logs du serveur et bannit automatiquement les adresses IP qui multiplient les tentatives de connexion échouées.

Installation

sudo apt update && sudo apt install fail2ban -y

Configuration pour PrestaShop

Créez un filtre dédié au back-office PrestaShop :

sudo nano /etc/fail2ban/filter.d/prestashop-admin.conf

[Definition]
failregex = ^<HOST> .* "POST .*/index\.php\?controller=AdminLogin.* 200
ignoreregex =

Puis activez la jail dans /etc/fail2ban/jail.local :

[prestashop-admin]
enabled = true
port = http,https
filter = prestashop-admin
logpath = /var/log/apache2/access.log
maxretry = 5
bantime = 3600
findtime = 600

Ce paramétrage bannit une IP pendant 1 heure après 5 tentatives échouées en 10 minutes.

Jails complémentaires indispensables

[sshd]
enabled = true
maxretry = 3
bantime = 86400

[apache-auth]
enabled = true
maxretry = 3
bantime = 3600

Autoriser Google à lire CSS et JavaScript

Depuis 2015, Google exige de pouvoir accéder aux fichiers CSS et JavaScript de votre site pour un rendu correct des pages. Bloquer ces ressources via robots.txt ou des restrictions serveur pénalise directement votre référencement.

Vérifier dans robots.txt

Assurez-vous que votre fichier robots.txt n'interdit pas l'accès aux assets :

# Mauvais - bloque le rendu Google
Disallow: /themes/
Disallow: /js/
Disallow: /css/

# Correct - laisse Google accéder aux ressources de rendu
Allow: /themes/*/assets/
Allow: /themes/*/css/
Allow: /themes/*/js/

PrestaShop 8.x : Le fichier robots.txt est généré dynamiquement par le module gsitemap. Vérifiez les règles via SEO & URL > Génération du fichier robots.txt dans le back-office.

Tester avec Google Search Console

Utilisez l'outil Inspection d'URL de la Search Console pour vérifier que Google voit votre page correctement. Si des ressources sont bloquées, un avertissement apparaît dans le rapport de rendu.

Checklist récapitulative avant lancement

Point de contrôlePrioritéVérifié Dossier admin renommé (15+ caractères)Critique☐ Double auth HTTP sur le back-officeHaute☐ Aucun dossier en chmod 777Critique☐ phpMyAdmin masqué ou désactivéHaute☐ Fail2Ban installé et configuréHaute☐ SSL/TLS activé (HTTPS)Critique☐ robots.txt autorise CSS/JSHaute☐ Clés API et mots de passe modifiésCritique☐ Fichier `.env` hors du web publicCritique☐ Debug mode désactivéCritique☐

Aller plus loin : sécurisation avancée

Pour les boutiques traitant un volume significatif de transactions, considérez également :

• **Headers de sécurité HTTP** : Content-Security-Policy, X-Frame-Options, Strict-Transport-Security
• **WAF (Web Application Firewall)** : ModSecurity avec les règles OWASP CRS ou Cloudflare en reverse proxy
• **Mises à jour automatisées** : Activez les mises à jour de sécurité automatiques sur votre serveur (`unattended-upgrades` sur Debian/Ubuntu)
• **Monitoring** : Un outil comme CrowdSec (alternative communautaire à Fail2Ban) offre une protection collaborative basée sur les IP malveillantes détectées par la communauté
• **Sauvegardes chiffrées** : Planifiez des sauvegardes quotidiennes de la base de données et des fichiers, stockées hors du serveur de production

La sécurité n'est pas un état figé mais un processus continu. Chaque mise à jour de PrestaShop, chaque nouveau module installé doit déclencher une revue de ces points fondamentaux.