Security Audit Pro – Protégez votre boutique contre les attaques par l'IA - Module PrestaShop

Audit de sécurité pour PrestaShop : comprendre les risques et suivre les corrections

Les erreurs de configuration, les fichiers exposés et les modules vulnérables méritent d’être examinés avant qu’un incident survienne. Security Audit Pro regroupe des contrôles de sécurité PrestaShop dans le back-office : en-têtes HTTP, fichiers, administration, modules, WebService, code SQL, XSS/CSRF et permissions.

L’audit aide à décider quoi corriger et quoi faire vérifier. Il ne remplace pas un pentest professionnel et ne fournit pas de pare-feu ni de protection spécifique contre une technologie d’attaque.

Comment ça marche — 3 étapes

Étape 1 — Analyse : dans Modules → Gestionnaire de modules, recherchez Security Audit, cliquez sur Configurer, puis sur Lancer un audit. Mettez-le en pause et reprenez-le après un rechargement ; une interruption conserve les étapes déjà enregistrées.

Étape 2 — Examen : filtrez les constats par statut, catégorie ou recherche. Étape 3 — Suivi : faites examiner les recommandations, revérifiez un point précis puis comparez deux rapports pour suivre les changements.

Export pour votre développeur ou assistant IA

Le rapport texte rassemble les constats, leurs preuves disponibles et les recommandations. Transmettez-le à votre développeur ou à un assistant IA pour préparer des corrections adaptées ; l’export JSON convient à une analyse structurée.

Le module n’applique pas ces corrections. Une suspicion dans le code doit être confirmée avant toute modification ; faites relire et tester les changements proposés. Les nouveaux rapports excluent notamment les valeurs brutes de cookies et les secrets détectés par l’expurgation.

Rapports détaillés : constats, preuves et recommandations

Chaque constat indique son statut, sa portée, une explication, les preuves disponibles et une recommandation lorsqu’une action est utile. Une anomalie confirmée, une suspicion, un contrôle non vérifié et une erreur sont distingués d’un contrôle réussi.

Un chemin de fichier, un en-tête ou un module concerné vous aide à orienter la vérification. Les filtres remplacent les huit anciens onglets ; les détails s’ouvrent à la demande. Une explication aide le marchand à prioriser, sans garantir qu’il puisse réaliser seul une correction technique.

Section 1 — En-têtes HTTP et Configuration Serveur

Les en-têtes HTTP de votre serveur sont la première ligne de défense. Des en-têtes manquants ou mal configurés exposent votre boutique au clickjacking, aux attaques XSS, au MIME sniffing et aux fuites de données.

Vérifiez notamment HSTS, CSP, la protection contre l’intégration en iframe, X-Content-Type-Options, Referrer-Policy et Permissions-Policy. Le rapport relève aussi les versions serveur divulguées et certains attributs de cookies.

Lorsque la réponse HTTPS est exploitable, le contrôle vérifie le certificat et son échéance. La politique CORS observée sur la page publique reste une indication limitée ; elle ne valide pas tous les points d’entrée du site.

Section 2 — Fichiers et Répertoires Sensibles

L'un des vecteurs d'attaque les plus courants et dévastateurs : les fichiers qui ne devraient jamais être accessibles publiquement. Un seul fichier .env exposé peut livrer l'intégralité des identifiants de votre base de données à un attaquant.

Le module examine une liste bornée de chemins sensibles : fichiers .env, métadonnées Git, configuration PrestaShop, fichiers Composer, sauvegardes et journaux usuels. Il recherche aussi des indices de listage de répertoires.

Une réponse HTTP200 à une sonde de fichier devient une suspicion à confirmer, pas la preuve que son contenu est exposé. Une réponse inaccessible ou ambiguë est signalée comme non vérifiée.

Section 3 — Sécurité du Back-Office

Examinez le nom du dossier d’administration, les comptes employés concernés, certaines dates de connexion et les formats de mots de passe enregistrés. Une date absente ou invalide ne prouve pas qu’un compte est inactif.

Les modules de protection éventuellement détectés sont des indices : leur efficacité reste à vérifier. Le module ne lance pas de tentatives de connexion en force brute et ne certifie pas la protection du back-office.

Section 4 — Sécurité des Modules

Comparez les versions du cœur et des modules aux avis de sécurité présents dans le catalogue embarqué, avec leur source et la date de vérification. Repérez aussi les répertoires de modules non enregistrés et certains points d’entrée à examiner.

Ce catalogue couvre une sélection explicite d’avis ; l’absence de correspondance ne prouve pas qu’un module est sûr. Les points d’entrée susceptibles de modifier des données ne sont pas appelés par l’audit.

Section 5 — Audit de l'API WebService

Contrôlez l’activation du WebService, l’usage de HTTPS et la réponse anonyme de /api/. Le module examine la longueur et la diversité des clés actives de la boutique ainsi que certaines permissions d’écriture sensibles.

Le rapport contient des nombres et des observations, sans exporter les valeurs des clés. Un indice d’accès anonyme ou de droits étendus doit être examiné dans son contexte ; aucune ressource client n’est extraite pour prouver une intrusion.

Section 6 — Indices d’injection SQL et analyse de code

Une requête limitée sur la recherche vérifie la divulgation éventuelle d’erreurs SQL. Une lecture bornée de fichiers PHP dans les modules et overrides relève certains appels et motifs à examiner, sans exécuter le code analysé.

Ces indices statiques sont des suspicions, pas des injections exploitables confirmées. La profondeur, le nombre et la taille des fichiers analysés sont limités ; une limite atteinte reste visible dans le rapport.

Section 7 — Vérifications XSS et CSRF

Le Cross-Site Scripting (XSS) permet aux attaquants d'injecter des scripts malveillants dans vos pages, volant ainsi les cookies des clients, les jetons de session et les données personnelles. Le Cross-Site Request Forgery (CSRF) trompe les utilisateurs authentifiés pour leur faire effectuer des actions indésirables.

Une sonde de recherche utilise un marqueur HTML inerte pour repérer un reflet à examiner. Aucun script exécutable n’est envoyé. La politique CSP fait partie des observations d’en-têtes.

La présence d’un champ de jeton sur le formulaire de contact ne démontre pas sa validation côté serveur : le contrôle CSRF reste non vérifié et demande un examen complémentaire.

Section 8 — Permissions et Contrôle d'Accès

Examinez certaines permissions de fichiers de configuration, la présence de règles Apache dans des dossiers d’envoi et une réponse de redirection, sans suivre la destination externe.

La présence d’un fichier .htaccess ne prouve pas que le serveur bloque l’exécution PHP. Le module n’essaie pas d’accéder aux commandes d’autres clients et ne certifie pas les contrôles de propriété des objets (IDOR).

Un score de A à F lorsque les contrôles le permettent

Les compteurs mettent en avant les constats critiques, les avertissements et les contrôles vérifiés. Une note globale n’est calculée que pour un audit terminé dont les contrôles applicables sont vérifiés ; sinon, elle reste absente avec une explication.

Un constat critique limite la note calculable. Ni une note élevée ni un contrôle réussi ne constituent une garantie de sécurité globale ; la couverture et les preuves restent essentielles à l’interprétation.

Tableau de bord, Historique et Comparaison

Retrouvez vos audits datés, ouvrez les rapports au besoin et comparez leurs constats : nouveaux, persistants, résolus ou non vérifiés. Une absence de contrôle ne devient pas automatiquement une correction confirmée.

La pause, la reprise et l’annulation vous permettent de garder la main. Après une mise à jour de module ou une intervention technique, revérifiez le constat concerné et suivez l’évolution dans l’historique.

Des contrôles bornés, sans modification automatique de la boutique

Les contrôles lisent les fichiers et réglages audités sans les corriger automatiquement. Le module enregistre ses propres rapports et son état de progression. Les requêtes HTTP sont limitées, restent sur la boutique configurée et ne suivent pas les redirections.

Aucun script du module n’est ajouté à la vitrine. Le travail d’audit consomme néanmoins des ressources pendant son exécution ; sa durée dépend de la boutique et de l’hébergement. Vous pouvez le suspendre ou l’annuler.

Historique par boutique en multiboutique

Sélectionnez une boutique pour consulter et lancer ses audits. Les nouveaux rapports et comparaisons sont séparés par boutique ; certains constats sur les fichiers partagés sont identifiés comme tels.

Les anciennes archives sans attribution fiable à une boutique sont réservées au superadministrateur et exclues des comparaisons. Les droits des employés restent contrôlés, y compris pour la lecture, les audits et la suppression.

Compatibilité et fonctionnement

Accès uniquement depuis le Gestionnaire de modules, via Configurer, sans entrée supplémentaire dans le menu latéral. L’interface et les rapports sont disponibles en français, anglais, espagnol, italien et polonais.

PrestaShop 1.7.8, 8 et 9 ; PHP 7.4 minimum, dans une version également compatible avec votre PrestaShop. Extensions requises : JSON, PDO, mbstring, cURL et OpenSSL. Le module utilise une interface locale, sans bibliothèque distante, et ne nécessite aucune compilation chez le marchand.

À qui s'adresse ce module ?

Pour les marchands qui veulent comprendre les constats avant de faire intervenir leur développeur ; pour les agences qui suivent plusieurs boutiques ; pour les développeurs qui souhaitent examiner des indices dans les fichiers et comparer les résultats après une correction.

Un audit spécialisé reste nécessaire pour confirmer des soupçons et examiner les protections qui ne peuvent pas être validées automatiquement.

Lire le guide d’audit de sécurité et de suivi des corrections