Comment auto-auditer votre boutique PrestaShop — Module gratuit Security Scan

Deux façons de vérifier votre boutique

Pour un aperçu rapide en quelques secondes, utilisez notre Security Scanner public : saisissez l'URL de votre boutique et il identifie passivement vos versions de PrestaShop et de PHP, vérifie si cette version est exposée publiquement ou en fin de vie, et inspecte vos en-têtes de sécurité HTTPS — aucune installation, rien à configurer. Il ne lit que ce que n'importe quel visiteur voit déjà.

C'est aussi sa limite. Un check public ne peut pas dire quelles versions de modules vous utilisez réellement, quelles sont vos permissions de fichiers, si le mode debug est activé, ni si une sauvegarde .sql traîne dans votre racine web — or c'est précisément cette dernière catégorie qui fait pirater la plupart des boutiques PrestaShop. Pour cela, installez le module gratuit Security Scan : il analyse votre boutique de l'intérieur, où le consentement est acquis par nature, puisque c'est votre boutique. Ce guide vous montre comment le lancer, comment lire le rapport et — avec de vraies commandes — comment corriger ce qu'il trouve. Pour la référence complète de durcissement, notre checklist de durcissement de la sécurité PrestaShop va plus loin.

Ce que vérifie un scan local

Le rapport est regroupé par domaine — d'abord les vérifications confirmées (versions, fichiers exposés), puis les vérifications heuristiques (malware et code), clairement signalées comme telles. Chaque constat indique ce qui a été trouvé, pourquoi c'est important et comment le corriger.

Les groupes malware et code sont heuristiques à dessein — des estimations éclairées qui signaleront parfois quelque chose d'anodin. Nous préférons vous montrer un faux positif que vous écartez en dix secondes plutôt que de rater silencieusement un web shell.

Chaque constat est vérifiable. Chaque correspondance de version et de CVE renvoie directement à l'avis officiel — la fiche CVE ou le GitHub Security Advisory de l'éditeur — et porte un niveau de confiance, pour que vous puissiez vérifier chaque signalement vous-même au lieu de nous croire sur parole. Lorsque le scanner ne peut que déduire quelque chose, ou ne peut pas confirmer un réglage de l'extérieur, il le dit clairement et lui attribue un score faible. Il est conçu pour être précis, pas alarmiste.

Comment le lancer

Installez et activez le module gratuit Security Scan, puis ouvrez Configurer → Security Scan → Scan & Report et cliquez sur Run scan now. Un scan typique prend quelques secondes. Les vérifications ne font que lire les fichiers, la configuration et la base de données de votre boutique ainsi que vos propres URL publiques ; le module n'écrit que son propre historique de scan, il ne modifie donc jamais les fichiers de la boutique, les réglages, les produits, les commandes ou les clients — sans risque sur une boutique en production.

Vous préférez la ligne de commande, ou l'automatisation ? Vous pouvez déclencher le même scan local depuis un contexte PrestaShop bootstrappé (le garde-fou l'empêche de s'exécuter via le web si vous oubliez le fichier) :

<?php
// scan-now.php — run from the CLI only; delete the file if you place it in the shop root
if (PHP_SAPI !== 'cli') {
    http_response_code(403);
    exit;
}

require __DIR__ . '/config/config.inc.php';
require __DIR__ . '/modules/mprsecurityscan/vendor/autoload.php';

$run = \MPRSecurityScan\Service\ScanRunner::runAndStore('manual');
printf("Score %d/100 (grade %s) — %d issues\n",
    $run['result']['score'], $run['result']['grade'], $run['result']['problem_count']);

Comment lire votre score

Vous obtenez un nombre unique sur 100 et une note en lettre. Le score démarre à 100 et perd des points pour chaque problème réel, pondéré par la sévérité — un problème critique coûte bien plus qu'un problème mineur. Les vérifications réussies sont également affichées, pour voir ce qui a réellement été vérifié.

• Critique −30 chacun — exploitable maintenant, ou exposition confirmée. À corriger aujourd'hui.
• Élevé −15 — sérieux ; à corriger cette semaine.
• Moyen −7 — lacunes notables de durcissement ou d'hygiène.
• Faible −3 — améliorations mineures.

Le tout se traduit en une note — A 90+, B 75+, C 60+, D 40+, F en dessous de 40. Considérez le score comme un outil de priorisation, pas comme une garantie : un score élevé signifie que le scanner n'a trouvé aucun problème connu dans ce qu'il peut voir.

Exemple concret : un répertoire .git exposé

C'est l'un des constats les plus fréquents — et les plus dangereux. Si vous avez déployé via git clone ou git pull dans votre racine web, tout le dossier .git (avec l'historique complet de vos sources et tous les secrets jamais committés) peut être téléchargeable. Le scanner le confirme en demandant réellement /.git/HEAD via HTTP et en vérifiant que la réponse ressemble à des métadonnées de VCS.

Critique — des métadonnées de VCS sont accessibles publiquement. Le scanner a confirmé que /.git/HEAD renvoie des métadonnées de VCS via HTTP.

Corrigez en deux étapes. D'abord, depuis la racine de votre boutique, sauvegardez les métadonnées puis supprimez-les (les garde-fous garantissent que rien n'est supprimé tant que la sauvegarde n'a pas réussi) :

# run from your shop root
set -eu

paths=()
[ -d .git ] && paths+=(.git)
[ -d .svn ] && paths+=(.svn)

if [ "${#paths[@]}" -gt 0 ]; then
  tar czf "$HOME/vcs-metadata-backup-$(date +%F-%H%M%S).tgz" "${paths[@]}"
  rm -rf "${paths[@]}"
fi

Ensuite, assurez-vous que le serveur web refuse les répertoires commençant par un point, même si l'un d'eux réapparaît. Apache (.htaccess ou vhost) — ceci refuse les fichiers à point et les chemins de répertoires à point comme /.git/HEAD, tout en conservant /.well-known/ :

<FilesMatch "^\.">
  Require all denied
</FilesMatch>

RedirectMatch 404 "(^|/)\.(?!well-known(?:/|$))"

Ou nginx :

location ^~ /.well-known/ {
    try_files $uri =404;
}

location ~ /\.(?!well-known(?:/|$)) {
    return 404;
}

Relancez le scan ; le constat devrait disparaître (l'URL renvoie désormais 403/404). Si un secret a un jour figuré dans cet historique, révoquez-le et remplacez-le.

Que corriger en premier (avec les commandes)

Traitez le rapport de haut en bas. Voici les corrections pour les constats que vous verrez le plus souvent.

Archives de sauvegarde dans la racine web

Un store.sql ou un backup.zip à côté de index.php est une copie complète de votre boutique, à une simple tentative de devinette près. Listez-les, puis déplacez chaque correspondance hors du docroot (mv -n n'écrase jamais) :

# review the list first
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) -ls

# then move every match out of the webroot
mkdir -p "$HOME/private-backups"
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) \
  -exec mv -n -- {} "$HOME/private-backups/" \;

Répertoire /install résiduel

PrestaShop vous demande de le supprimer après l'installation. Plutôt que de le supprimer purement et simplement, mettez-le en quarantaine (à exécuter depuis la racine de votre boutique) :

# run from your shop root
set -eu
test -f config/config.inc.php

backup="$HOME/prestashop-install-dirs-$(date +%F-%H%M%S)"
mkdir -p "$backup"
[ -d install ] && mv install "$backup/"
[ -d install-dev ] && mv install-dev "$backup/"

Mode debug resté activé

Le mode développeur divulgue les stack traces et les chemins aux visiteurs. Modifiez la ligne existante dans config/defines.inc.php (ou config/defines_custom.inc.php) — n'en ajoutez pas une seconde en dessous :

<?php
// change the EXISTING _PS_MODE_DEV_ line to false (never true on a live shop)
define('_PS_MODE_DEV_', false);

Dossiers accessibles en écriture à tous (0777)

Le scanner signale les répertoires en 0777. Restaurez des permissions de moindre privilège — jamais de chmod 777, et gardez les fichiers de configuration secrets illisibles (un parameters.php lisible par tous est en soi un constat). À exécuter depuis la racine de votre boutique :

# run from your shop root; set these to your real PHP-FPM/web user + group
WEB_USER=www-data
WEB_GROUP=www-data

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

# lock down the secret config files: owned by the web user, readable by owner+group only
# (never world-readable — but still readable by the PHP process). Adjust owner/group above.
for f in app/config/parameters.php config/settings.inc.php; do
  [ -f "$f" ] || continue
  chown "$WEB_USER:$WEB_GROUP" "$f"
  chmod 640 "$f"
done

# only the writable dirs need to be owned by the web user
for dir in var/cache var/logs img upload download; do
  [ -d "$dir" ] || continue
  chown -R "$WEB_USER:$WEB_GROUP" "$dir"
  find "$dir" -type d -exec chmod 775 {} \;
  find "$dir" -type f -exec chmod 664 {} \;
done

.htaccess faible ou manquant

Régénérez les règles de protection de PrestaShop depuis le Back Office (Paramètres de la boutique → Trafic & SEO → Régénérer le fichier .htaccess), puis vérifiez que les fichiers sensibles sont bloqués et que le listage de répertoires est désactivé. Une protection minimale :

<FilesMatch "(?i)(parameters\.php|settings\.inc\.php|\.env|composer\.(json|lock))$">
  Require all denied
</FilesMatch>

Options -Indexes

Les limites de la détection seule

Être honnête sur les limites fait partie du bon usage de tout outil de sécurité : il détecte les problèmes, il ne les corrige pas à votre place ; les vérifications heuristiques peuvent signaler des éléments anodins (vérifiez avant de supprimer) ; la couverture des avis de sécurité est soigneusement tenue, mais pas exhaustive ; et ce n'est pas un test d'intrusion. Pour la référence complète de remédiation — durcissement du serveur, verrouillage de l'admin, base de données et surveillance — suivez la checklist de durcissement de la sécurité.

Quand arrêter de scanner et demander de l'aide

Certains constats signifient qu'il faut une personne, pas un outil. Des fichiers d'allure malveillante, tout ce qui ressemble à un skimmer de paiement, des comptes admin que vous ne reconnaissez pas, des identifiants exposés ou des réinfections à répétition — c'est un incident. Si vous préférez nous le confier, réservez un audit de sécurité.

Quand les corrections automatiques ont du sens

Le scanner gratuit est volontairement à usage ponctuel : vous le lancez, vous lisez le rapport, vous corrigez à la main. Parfait pour un bilan occasionnel. Si vous préférez ne pas le faire manuellement — ou si vous voulez rester corrigé — Security Revolution applique des corrections en un clic, durcit votre boutique, surveille l'intégrité des fichiers du cœur, vous alerte quand quelque chose change et gère toute une flotte de boutiques depuis un seul tableau de bord. Les mêmes constats ; il agit simplement dessus et continue de veiller.

FAQ

Le scan envoie-t-il mes données quelque part ? Pour un scan autonome via le tableau de bord ou la CLI, non — le rapport reste sur votre serveur, et les seules requêtes sortantes sont des auto-vérifications vers vos propres URL publiques, protégées contre l'accès aux adresses internes (SSRF). Si vous inscrivez explicitement le connecteur de flotte optionnel, les résultats de scan sont envoyés — via un canal signé — au hub que vous avez configuré.

Corrige-t-il les problèmes automatiquement ? Non — ce module fait uniquement de la détection. Les corrections automatiques et la surveillance sont dans Security Revolution.

Est-il sans risque sur une boutique en production ? Oui. Il lit vos fichiers, votre configuration et votre base de données et n'écrit que son propre historique de scan — il ne modifie jamais le contenu de la boutique, les réglages, les produits, les commandes ou les clients.

À quelle fréquence dois-je scanner ? Après chaque mise à jour de PrestaShop ou d'un module, et au moins une fois par mois. La page Historique suit votre score dans le temps.

Peut-il remplacer un développeur ? Non. C'est une première passe rapide et utile qui attrape les risques courants et bien connus. Les audits approfondis et les vrais incidents nécessitent toujours un humain.

Lectures associées

• Durcissement de la sécurité PrestaShop : la checklist complète — le compagnon de remédiation de cette page.
• Security Scan — le module gratuit décrit ici.
• Security Revolution — corrections automatiques, durcissement et surveillance de l'intégrité des fichiers.