Sécuriser une boutique PrestaShop : la checklist essentielle

Vérifier que votre version reçoit encore des correctifs

C'est le point numéro un, et de loin. La branche PrestaShop 1.7 a atteint sa fin de vie : elle ne reçoit plus de correctifs pour les nouvelles vulnérabilités découvertes. Rester dessus signifie que chaque faille publiée dans le cœur reste ouverte indéfiniment sur votre boutique, et que les robots qui scannent le web savent exactement quoi tester. PrestaShop 8 est encore maintenu, et PrestaShop 9, sorti en 2025, est la branche alignée sur les versions récentes de PHP.

Le sujet est doublement urgent parce qu'il se cumule avec PHP : une boutique 1.7 est généralement bloquée sur une version de PHP elle-même en fin de vie, que les hébergeurs finissent par retirer. Vous vous retrouvez alors avec un site qui tombe du jour au lendemain, et une migration à mener dans l'urgence plutôt qu'au calme.

Pour savoir où vous en êtes sans vous connecter au back-office : un audit de surface détecte les signatures de version laissées dans les en-têtes HTTP, le code source et les chemins de fichiers, et signale les composants en fin de vie. C'est aussi ce que voit un attaquant.

Supprimer ou verrouiller les dossiers et fichiers sensibles

Le dossier /install doit disparaître après l'installation : laissé en place, il permet dans certains cas de relancer une procédure de configuration. Le dossier d'administration, lui, reçoit un nom aléatoire à l'installation (du type admin7f3k2) — c'est volontaire, ne le renommez jamais en /admin ou /administration, qui figurent en tête des listes testées automatiquement.

Le fichier le plus critique est /app/config/parameters.php : il contient les identifiants de votre base de données et les clés de chiffrement des cookies. Il ne doit jamais être servi en HTTP. Testez-le à la main dans votre navigateur : vous devez obtenir une erreur, jamais du contenu. Même vigilance pour un dossier .git laissé lors d'un déploiement, et pour les exports de base ou archives .zip déposés à la racine « le temps d'une manipulation » puis oubliés.

Dernier réflexe : le mode debug. Défini dans config/defines.inc.php, la constante _PS_MODE_DEV_ doit être à false en production. Laissée à true, elle affiche les traces d'erreur complètes — chemins serveur, requêtes SQL, version des composants — à quiconque provoque une erreur.

# Fichier de configuration (identifiants base de données)
<FilesMatch "^(parameters\.php|parameters\.yml|\.env)$">
  Require all denied
</FilesMatch>

# Archives, exports et fichiers de sauvegarde
<FilesMatch "\.(sql|zip|tar|gz|bak|old|log)$">
  Require all denied
</FilesMatch>

# Dossiers de versionnement
RedirectMatch 404 /\.git

define('_PS_MODE_DEV_', false);

Reprendre le contrôle des modules et des comptes employés

Les modules tiers sont la première porte d'entrée réelle sur PrestaShop. Deux règles simples : mettez-les à jour au même rythme que le cœur, et surtout supprimez ceux que vous n'utilisez plus. Désactiver un module ne suffit pas — ses fichiers restent présents sur le serveur et restent atteignables par leur URL directe. Passez en revue votre liste : un module de transporteur ou de paiement abandonné par son auteur, dont la dernière mise à jour remonte à plusieurs années, est un risque net qu'il vaut mieux remplacer.

Côté accès, PrestaShop 8 intègre nativement la double authentification pour les comptes employés : activez-la, en commençant par les profils SuperAdmin. Appliquez aussi le principe du moindre privilège — un gestionnaire de commandes n'a aucun besoin d'accéder aux paramètres avancés ni au gestionnaire de fichiers. Et révoquez sans délai les comptes des prestataires dont la mission est terminée : les accès d'agence oubliés sont un classique des post-mortem.

Durcir la couche HTTPS et les en-têtes

Activez le SSL sur toutes les pages (Paramètres de la boutique → Général), et pas seulement sur le tunnel de commande : un cookie de session transmis une seule fois en clair suffit à compromettre le compte. Vérifiez ensuite que la redirection HTTP vers HTTPS est bien en place et qu'aucune ressource du thème n'est encore appelée en http:// — ce contenu mixte fait disparaître le cadenas et bloque les ressources concernées.

Un piège propre à PrestaShop mérite d'être connu : le fichier .htaccess est régénéré automatiquement par la boutique (Paramètres avancés → Performances). La régénération réécrit le bloc délimité par les commentaires ~~start~~ et ~~end~~. Placez donc vos directives personnalisées — en-têtes de sécurité, protections de fichiers — en dehors de ce bloc, et vérifiez qu'elles sont toujours là après chaque régénération.

Une fois ces réglages posés, relancez un audit : CheckCyber contrôle en une passe le certificat, la redirection, les en-têtes de sécurité, les cookies, les fichiers exposés et les bibliothèques JavaScript vulnérables de votre thème, et vous indique lesquels manquent encore.

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>