Sécurité PrestaShop : durcissement, accès et restauration

Ce que nous ferions

Nous déterminerions d'abord si vous cherchez à prévenir un problème ou réagissez à des indices de compromission. Pour un durcissement courant, inventoriez l'existant avant de choisir des outils : hébergement, PrestaShop et PHP, modules, intégrations, personnalisations du thème, données stockées, marchés et personnes ayant besoin d'accès. Une intégration d'entrepôt, une équipe d'assistance mobile et un formulaire de paiement intégré imposent des besoins différents. Conservez les contrôles efficaces et traitez les lacunes démontrables.

Si votre boutique ne peut pas utiliser des logiciels maintenus, comparez une mise à niveau de l'installation existante à une installation cible propre avec migration contrôlée des données. Le bon choix dépend de votre code personnalisé, des remplacements de modules, du thème, des intégrations et de la qualité des données. Durcir une boutique non maintenue limite certains risques pendant ces travaux ; cela ne rétablit pas la maintenance de l'éditeur. Si une compromission est suspectée, préservez les preuves et suivez la section de réponse aux incidents avant de considérer la boutique comme une copie de départ sûre.

Pour les changements planifiés, utilisez une copie de préproduction protégée, répétez les parcours métier concernés, consignez le retour arrière et convenez d'une bascule en production avec un responsable qui en surveille le résultat. Une migration de plateforme ou de base nécessite aussi un plan pour les commandes et autres écritures reçues pendant la préparation de la copie.

Pour une évaluation indépendante, le service PrestaShop Security Audit & Hardening Report examine l'exposition convenue et fournit un plan priorisé ; la mise en œuvre et la remédiation d'incident sont définies séparément.

Commencer par la prévention, la détection et la restauration

Protégez la boutique à plusieurs niveaux : logiciels maintenus, connexions individuelles, permissions restreintes, règles serveur, filtrage du trafic, surveillance et sauvegardes restaurables. HTTPS protège les données en transit. Une sauvegarde aide à restaurer. Aucun des deux ne remplace les correctifs.

Les risques comprennent les injections SQL dans le cœur ou les modules, le vol d’identifiants d’employés, les téléversements vulnérables, les paquets malveillants et les sauvegardes ou configurations exposées. Le tunnel de commande peut encore fonctionner alors qu’un JavaScript injecté vole des données. Une petite boutique a aussi besoin de ces contrôles.

1. Consignez vos versions exactes de PrestaShop, PHP, de la base de données, du thème et des modules.
2. Sauvegardez les fichiers et la base, puis prouvez que vous pouvez les restaurer sur une copie isolée.
3. Appliquez les correctifs de sécurité en préproduction et testez le tunnel de commande avant la production.
4. Donnez à chaque employé un compte unique, un mot de passe fort et un second facteur.
5. Examinez les chemins accessibles en écriture, les points d’entrée publics et les alertes de surveillance.

Attribuez un responsable et une date de révision à chaque contrôle. Revoyez les accès après les changements de personnel et répétez régulièrement l’examen global. Protégez la préproduction par authentification et désactivez-y les paiements réels, les emails clients et les intégrations de production.

Utiliser des versions maintenues de PrestaShop et de PHP

Compatibilité et maintenance de sécurité sont deux questions distinctes. PrestaShop 8.0 à 8.2 prend en charge PHP jusqu’à 8.1 seulement. PrestaShop 9.0 prend en charge PHP 8.1 à 8.4 ; 9.1 prend en charge 8.1 à 8.5. La version 9.2 prend aussi en charge PHP 8.1 à 8.5. Vérifiez la version exacte et chaque module avant de changer PHP. Consultez le tableau de compatibilité et les prérequis de la version 9.2.

Au 26 octobre 2026, PHP 8.1 est déjà en fin de vie. Son support de sécurité amont a pris fin le 31 décembre 2025. Le support de PHP 7.4 a pris fin le 28 novembre 2022. Vérifiez le cycle de vie de PHP ainsi que la compatibilité de la plateforme. Prévoyez une mise à niveau de la plateforme si votre boutique ne peut pas utiliser un environnement maintenu ; validez explicitement toute offre de support étendu.

La maintenance amont régulière de PrestaShop 1.7 a pris fin à la sortie de 9.0. Un correctif exceptionnel ultérieur ne constitue pas une maintenance continue de la branche. PrestaShop 1.6 ne bénéficie plus non plus de maintenance officielle. Suivez la politique de maintenance et planifiez votre migration.

Appliquez aussi les correctifs du système d’exploitation, de la base de données, du serveur web et des modules. Tenez un inventaire des modules et abonnez-vous aux avis des fournisseurs et aux avis de sécurité de Friends of Presta. Un numéro de version seul ne prouve pas qu’un exploit précis s’applique.

Utilisez la checklist de migration pour planifier les changements de versions de PHP et de PrestaShop.

Répéter le changement et le retour arrière

Par exemple, renforcer les règles de téléversement peut protéger les pièces jointes clients tout en cassant un module qui les traite via un ancien point d'entrée. Consignez d'abord les routes réellement utilisées par ce module. Testez séparément les téléversements normaux et le blocage des noms de fichiers exécutables, afin qu'une image produit fonctionnelle ne masque pas un processus de pièces jointes défaillant.

1. Conservez la configuration actuelle, les chemins concernés, les accès des intégrations et un point de restauration concordant des fichiers et de la base. Consignez le comportement attendu avant tout changement.
2. Créez la copie protégée avec les mêmes gestionnaires serveur, règles de proxy, modules et thème pertinents. Limitez l'accès aux données clients copiées et remplacez les destinations de production par des services de test ou des simulacres contrôlés.
3. Appliquez un changement logique à la fois. Changer simultanément PHP, un module et le pare-feu rend l'origine d'un échec plus difficile à identifier.
4. Testez les actions autorisées et refusées : connexion et récupération employé, tentative d'accès hors rôle, navigation catalogue, téléversements, commande, notifications de paiement, remboursements, tâches planifiées et synchronisations partenaires selon le cas.
5. Répétez le retour arrière. Restaurer un fichier de configuration, rétablir du code déployé et restaurer une base ont des conséquences différentes ; identifiez ce que le changement exige et qui peut le faire.
6. Convenez du créneau, des contrôles autorisant la bascule et du déclencheur de retour arrière. Si des données passent entre installations, définissez la suspension ou le rapprochement des écritures et le traitement des notifications de paiement entrantes.
7. Après la bascule, vérifiez le traitement réel des commandes et le canal d'alerte. Conservez les résultats de test, réglages modifiés et consignes de maintenance pour la prochaine version.

Une restauration de base peut effacer les commandes passées après le point de restauration. Pour revenir sur une migration, convenez du rapprochement de ces commandes et des paiements prestataires avant le retour. Gardez l'ancien environnement protégé pendant sa conservation pour reprise.

Pour une ancienne boutique nécessitant une plateforme maintenue, le service PrestaShop Upgrade Service: Any Version to PrestaShop 9 évalue la version existante, PHP, l'hébergement, le thème et les modules avant un devis écrit, puis intervient en préproduction avant la bascule réelle.

Trouver ou modifier l’URL du back-office

Le back-office se trouve dans un répertoire physique à la racine de la boutique. Si la boutique est installée sous /shop/, incluez ce chemin de base avant le répertoire d’administration. Utilisez SFTP, le gestionnaire de fichiers de l’hébergeur ou SSH pour le trouver.

Repérez la racine de la boutique contenant classes/, modules/ et themes/. Les noms des répertoires candidats commencent souvent par admin, mais un répertoire renommé peut porter un autre nom. Inspectez son index.php pour trouver l’amorçage de l’administration et la définition de _PS_ADMIN_DIR_. Un sous-répertoire controllers/ n’y est pas requis.

Le fichier standard app/config/parameters.php ne stocke pas le nom du dossier d’administration. Gardez confidentiel le nom aléatoire existant ou renommez le dossier réel pendant un créneau d’accès coordonné. Aucun paramètre standard de la base de données ne doit être modifié pour lui correspondre.

1. Gardez un accès SFTP ou hébergeur fonctionnel.
2. Demandez aux collègues de se déconnecter, puis renommez le répertoire.
3. Mettez à jour toute référence à l’ancien chemin dans les proxys, pare-feu, tâches planifiées ou modules personnalisés.
4. Ouvrez la nouvelle URL HTTPS et testez la connexion.
5. Mettez à jour les favoris et les entrées du gestionnaire de mots de passe. Vérifiez que l’ancien chemin n’ouvre plus le back-office.

Un lien symbolique depuis l’ancien nom garde ce point d’entrée accessible. Un chemin privé réduit les scans opportunistes, mais exige toujours une authentification forte et des restrictions d’accès.

Mots de passe, authentification à deux facteurs et sessions des employés

Sur les versions modernes, ouvrez Paramètres avancés > Équipe > Employés, Profils et Permissions. Dans PrestaShop 1.6, ces pages se trouvent sous Administration. Donnez à chacun un compte employé nominatif. Évitez de partager le compte du propriétaire.

Utilisez des mots de passe longs et uniques générés par un gestionnaire. Un mot de passe aléatoire d’au moins 16 caractères est une règle pratique. Changez rapidement les mots de passe compromis ou réutilisés. Une rotation forcée régulière ne remplace pas la longueur et l’unicité. Le cœur moderne utilise son service Crypto Hashing avec bcrypt et vérification des anciens hachages ; ne réinitialisez pas les mots de passe avec du MD5 brut.

Le TOTP du back-office nécessite un module compatible ou une couche externe d’identité/accès. Le cœur ne fournit pas l’interrupteur TOTP universel décrit dans de nombreux anciens tutoriels. Un fournisseur d’identité externe peut aussi imposer une MFA individuelle. Le TOTP réduit les attaques fondées uniquement sur le mot de passe, mais un attaquant peut relayer un code courant par hameçonnage. Une authentification WebAuthn/FIDO bien implémentée offre un autre niveau de résistance à l’hameçonnage. Consultez les recommandations d’authentification du NIST.

Testez l'inscription et la récupération avant d'imposer le second facteur à l'équipe. Conservez les codes de secours hors du téléphone, vérifiez les horloges du serveur et du téléphone et documentez la récupération de l'outil. Le cœur n'a pas de colonnes 2FA standard d'employé à effacer.

Security Revolution ajoute le TOTP employé, les codes de secours, les contrôles de connexion, la gestion des en-têtes de sécurité et les comparaisons de fichiers avec une référence ; suivez son aide pour la configuration et la récupération.

Distinguer expiration du cookie et inactivité

PS_COOKIE_LIFETIME_BO est exprimé en heures. Il contrôle la durée du cookie, pas une politique générale d'inactivité. La connexion persistante et les contrôles d'inactivité diffèrent selon la version ; PrestaShop 1.7.8 possède un contrôle distinct d'une heure depuis la dernière activité dans le mode de connexion concerné. Testez la déconnexion réelle.

PS_PASSWD_TIME_BACK est mesuré en minutes et concerne la dernière génération de mot de passe. Il ne garantit pas un délai entre demandes d’email de réinitialisation. Ajoutez une limitation distincte des demandes si nécessaire.

Exigez HTTPS et inspectez le cookie d’administration réel pour les indicateurs Secure et HttpOnly et une politique SameSite appropriée. Les paramètres PHP de cookie de session ne contrôlent pas nécessairement tous les cookies PrestaShop. Verrouillez les postes sans surveillance et révoquez les sessions lorsqu’un appareil ou un compte est compromis.

Vérifier l'inscription et la récupération d'un employé ordinaire

1. Utilisez un employé nominatif avec le profil de droits prévu, plutôt que de tester uniquement avec SuperAdmin.
2. Terminez l'inscription, déconnectez-vous et testez une nouvelle connexion. Confirmez que la route protégée reste inaccessible en sautant la page du second facteur.
3. Testez la récupération documentée en cas d'appareil perdu avec une personne autorisée disponible. Confirmez ce que la récupération invalide et comment l'employé inscrit un nouvel appareil.
4. Vérifiez l'inscription de chaque employé actif, y compris les prestataires et comptes occasionnels. Définissez qui approuve une exception et quand elle expire.

Le CAPTCHA des formulaires clients et l'authentification des employés protègent des surfaces distinctes. Protéger la connexion en boutique ne prouve pas que la connexion au back-office est couverte ; testez la route réelle des employés.

Restreindre l’accès et détecter les échecs de connexion

Si votre équipe utilise une adresse de bureau stable ou un VPN, limitez le back-office au niveau du proxy ou du serveur. Conservez une voie de récupération autorisée et testez depuis des adresses admises et refusées. Avec un proxy inverse, configurez la gestion fiable des IP clientes avant d'utiliser des règles IP.

Pour Apache 2.4, voici un exemple destiné à un répertoire d'administration dont le bureau autorisé utilise le réseau de documentation indiqué. Utilisez votre propre réseau approuvé lors du déploiement.

Require ip 203.0.113.10
Require ip 198.51.100.0/24

Limitez la fréquence des échecs d’authentification avec un mécanisme testé sur le parcours de connexion de votre version. Ne déduisez pas l’échec des codes HTTP 200 ou 302 : les tentatives réussies et échouées peuvent partager ces codes. Un filtre fail2ban nécessite des journaux propres aux échecs et des tests prouvant qu’une connexion réussie n’est pas bannie.

Les journaux du cœur sont partiels. PrestaShop 1.6, 1.7.8 et 8.2 enregistrent les connexions réussies au back-office avec l'employé et l'IP source. Détection des échecs, analyse géographique et envoi d'alertes nécessitent leurs propres contrôles. Regroupez les journaux du proxy, de l'authentification et de l'application avec des horodatages synchronisés.

Les notifications personnalisées de connexion doivent utiliser la bonne intégration : les versions anciennes compatibles exposent actionAdminLoginControllerLoginAfter ; PrestaShop 9 utilise des événements d’authentification Symfony comme LoginSuccessEvent. Une alerte email fonctionnelle nécessite aussi des écouteurs enregistrés, de vrais modèles traduits, un chemin de modèles, une livraison réussie et une gestion des échecs.

Permissions des fichiers, identités d’hébergement et erreurs de cache

Identifiez l’identité du processus PHP avant de changer la propriété. Les workers PHP-FPM s’exécutent avec l’utilisateur et le groupe configurés pour le pool, qui peuvent différer de Nginx, d’Apache ou d’un processus maître root. Avec mod_php, PHP s’exécute dans le processus Apache. Avec un hébergement par compte ou suPHP, il peut s’exécuter sous l’utilisateur de votre hébergement.

Pour du code applicatif lisible ordinaire, les modes 755 pour les répertoires et 644 pour les fichiers sont des points de départ courants. Le droit d’exécution d’un répertoire autorise sa traversée. Le propriétaire, le groupe et les ACL déterminent qui peut écrire. Faire de l’utilisateur PHP le propriétaire de chaque fichier de code permet aussi à un PHP compromis de réécrire ces fichiers. Préférez du code appartenant au déploiement et des droits d’écriture d’exécution étroitement délimités si votre maintenance le permet.

Gardez app/config/parameters.php lisible par PHP sur PrestaShop 1.7, 8 et 9. L’ancienne version 1.6 utilise config/settings.inc.php. Un mode 400 généralisé peut casser la boutique si PHP n’est pas le propriétaire. N’appliquez pas 777 pour résoudre une erreur d’écriture. Un PHP vulnérable peut toujours écrire dans un répertoire 755 qui lui appartient.

Réparer une erreur d’écriture du cache après migration

1. Lisez le chemin exact de l’erreur et inspectez son propriétaire, son groupe, son mode et les droits de traversée des répertoires parents.
2. Vérifiez le worker réel de PHP-FPM et la configuration du pool.
3. Accordez à l’identité PHP requise les accès en lecture, écriture et traversée par la propriété, un groupe de confiance ou des ACL.
4. Une fois l’accès réparé seulement, supprimez le contenu de cache généré dans l’environnement concerné et préchauffez le cache avec l’utilisateur d’exécution prévu.
5. Si l’accès échoue encore, vérifiez espace disque, inodes, montages en lecture seule, SELinux/AppArmor, chemins chroot et umask de déploiement.

Cet exemple suppose que vous avez confirmé que le worker PHP s’exécute sous www-data et doit être propriétaire de ce cache. Il utilise des privilèges élevés pour tous les changements de mode et traite les fichiers séparément des répertoires.

sudo chown -R www-data:www-data /var/www/html/var/cache
sudo find /var/www/html/var/cache -type d -exec chmod 750 {} +
sudo find /var/www/html/var/cache -type f -exec chmod 640 {} +

Les chemins modernes accessibles en écriture incluent var/cache/, les journaux, img/, upload/ et download/. L’installation de modules, les changements de thème, les traductions et les mises à jour nécessitent des droits d’écriture temporaires supplémentaires. Les caches Smarty de l’ancienne version 1.6 peuvent se trouver sous cache/smarty/. Distinguez les permissions de mise à jour de celles de l’exécution courante de la boutique.

Dans Docker, comparez les UID/GID numériques à l'intérieur et à l'extérieur du conteneur. Les montages liés conservent les propriétaires de l'hôte. Les volumes nommés nécessitent aussi une initialisation et des propriétaires adaptés ; ils ne donnent pas automatiquement accès à PHP. Évitez un chown récurrent de toute l'arborescence en remplacement d'un modèle d'identité délibéré.

Pour les échecs de téléversement, vérifiez aussi les limites PHP d’upload. Pour une page blanche après chmod, vérifiez la traversée des répertoires et le journal PHP. Examinez les permissions du client SFTP et l’umask si les téléversements modifient constamment les modes.

Protéger la configuration, les fichiers téléversés et l’environnement PHP

Désactivez l'affichage de débogage en production. Définissez _PS_MODE_DEV_ à false dans config/defines.inc.php et vérifiez le contrôle Paramètres avancés > Performances > Mode debug applicable. Journalisez les erreurs vers une destination protégée. Examinez les réglages effectifs de la SAPI web plutôt que de vous fier à PHP en ligne de commande. Une base minimale comprend display_errors=Off, log_errors=On, expose_php=Off et allow_url_include=Off.

Désactiver des fonctions de processus comme exec, system, shell_exec, passthru, popen et proc_open peut limiter certaines charges malveillantes, mais aussi casser des traitements légitimes. Les pools PHP-FPM peuvent définir php_admin_value[disable_functions] en plus de php.ini. Redémarrez le bon service, vérifiez l’environnement web et testez le traitement des images, les imports et les tâches PDF. Cela n’empêche pas PHP de lire les données accessibles en écriture ou d’utiliser les identifiants de base de données.

open_basedir peut limiter les chemins, mais doit inclure tous les chemins temporaires et applicatifs légitimes. Considérez-le comme une restriction supplémentaire, pas comme un bac à sable. N’exposez pas en permanence un fichier phpinfo ou de shell de test.

Bloquer les chemins HTTP sensibles

Désactivez la liste des répertoires. Refusez l’accès public à la configuration, aux journaux, sauvegardes, exports SQL, métadonnées de dépôt et manifestes de dépendances. Gardez les sauvegardes hors de la racine web. Un fichier PHP de paramètres exécuté correctement n’affiche pas le tableau qu’il renvoie, mais la divulgation du code brut ou une copie de sauvegarde peut exposer les identifiants.

Préservez les chemins de certificats /.well-known/ nécessaires lorsque vous restreignez les fichiers cachés. Ne refusez pas aveuglément chaque fichier PHP de module : callbacks, tâches cron et anciens points d’entrée AJAX peuvent en dépendre.

Empêcher les scripts téléversés d’atteindre PHP

Couvrez img/, upload/ et download/, y compris les autres extensions exécutables et les noms à extensions multiples. Examinez la configuration réelle du gestionnaire PHP. Cet exemple d’hôte virtuel Apache 2.4 refuse les noms de fichiers exécutables courants dans ces chemins :

<DirectoryMatch "/var/www/html/(img|upload|download)(/|$)">
    <FilesMatch "(?i)\.(php[0-9]?|phtml|phar)(\.|$)">
        Require all denied
    </FilesMatch>
</DirectoryMatch>

DirectoryMatch doit figurer dans la configuration du serveur ou de l’hôte virtuel. php_admin_flag engine off est propre à mod_php et ne doit pas être copié sans protection dans une configuration PHP-FPM. Avec PHP-FPM, excluez aussi ces chemins de l’exécution FastCGI.

Sur Nginx, placez un bloc location de refus pour les noms exécutables avant le bloc location général qui traite PHP par expression régulière, adaptez-le à tout sous-répertoire de boutique et examinez tous les blocs location associés aux gestionnaires. Par exemple :

location ~* ^/(img|upload|download)/.*\.(php[0-9]?|phtml|phar)(\.|$) {
    return 403;
}
autoindex off;

Validez la configuration serveur, puis testez les noms bloqués et les images normales, les téléversements clients, les téléchargements et les callbacks de paiement. Adaptez les règles à chaque extension réellement exécutée par le serveur.

HTTPS, en-têtes de sécurité et CSP

Installez et renouvelez un certificat valide, activez SSL et SSL sur toutes les pages sous Paramètres de la boutique > Paramètres généraux dans les versions modernes, puis vérifiez les redirections HTTP, le tunnel de commande et le contenu mixte. Dans 1.6, les paramètres généraux se trouvent sous Préférences. Les navigateurs bloquent le contenu mixte actif comme les scripts et peuvent convertir les médias mixtes en HTTPS. Utilisez la console et l’onglet Réseau du navigateur pour les repérer.

Redirigez vers l’hôte de confiance configuré. Tenez compte de la terminaison TLS sur un proxy pour éviter les boucles. N’ajoutez HSTS qu’une fois HTTPS fiable ; utilisez includeSubDomains uniquement si chaque sous-domaine concerné prend en charge HTTPS.

Examinez X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, les restrictions d’intégration dans des cadres et une Permissions-Policy adaptée. Testez les paiements intégrés et les autres intégrations avant d’imposer des restrictions de cadres.

Déployer une Content Security Policy par étapes

default-src fournit des valeurs de repli. script-src contrôle les scripts ; style-src, img-src et font-src contrôlent les autres ressources ; connect-src contrôle les connexions des scripts. frame-src contrôle les cadres intégrés, tandis que frame-ancestors contrôle qui peut intégrer votre page. form-action limite les destinations d'envoi des formulaires. Envisagez object-src 'none' pour bloquer les contenus object et embed et base-uri 'self' pour limiter les URL de base, après test des intégrations. Définissez explicitement base-uri, form-action et frame-ancestors : ils n'héritent pas de default-src.

1. Commencez par Content-Security-Policy-Report-Only.
2. Inspectez les diagnostics du navigateur pendant les parcours produit, panier, compte, contact, commande, redirection et 3-D Secure.
3. Pour collecter les rapports, déployez un service de réception, configurez Reporting-Endpoints avec report-to et un repli report-uri approprié, puis prouvez qu’une violation volontaire de test arrive bien.
4. Construisez une liste d’autorisation à partir des origines réellement requises. Supprimez les autorisations larges https:, 'unsafe-inline' et 'unsafe-eval' lorsque la prise en charge compatible des nonces/hachages et des modèles le permet.
5. Passez à l’application effective après les tests et continuez à surveiller les rapports.

Un en-tête de simple rapport ne bloque rien. Sans récepteur fonctionnel, un journal serveur vide ne dit rien des violations. Ne faites pas automatiquement confiance aux origines rapportées et ne les ajoutez pas à votre liste d’autorisation. Les directives de reporting sont définies par CSP Level 3.

Une politique autorisant 'self' peut toujours autoriser un script local infecté ou un relais de même origine. Des contrôles d’intégrité des scripts protégés indépendamment, la surveillance du serveur et du code corrigé restent nécessaires.

Modules, accès à la base et points d’entrée publics

Installez les modules depuis des sources identifiables et responsables. Examinez la maintenance, les journaux de modifications, les correctifs de sécurité et l’intégrité des paquets. Des paquets non fiables ou modifiés peuvent contenir des logiciels malveillants. Une présence sur une place de marché réputée ne prouve pas l’absence de vulnérabilités.

Désactiver un module bloque normalement ses routes standard ModuleFrontController. Des scripts PHP autonomes peuvent rester exécutables. Avant de désinstaller un logiciel inutilisé, préservez les données métier et vérifiez les dépendances, callbacks et tâches planifiées ; supprimez ensuite ses fichiers.

La revue de code doit suivre les données des requêtes à travers l'autorisation, la validation des types, SQL, les écritures de fichiers et l'échappement des sorties. eval ou des charges exécutables décodées nécessitent un examen attentif. file_get_contents récupère des octets sans les exécuter : examinez la destination et l'utilisation ultérieure. L'exécution d'assertions sous forme de chaînes a été supprimée dans PHP 8. La conversion en entier et pSQL() traitent certaines entrées SQL ; elles ne constituent pas une revue de sécurité complète.

Utilisez un compte de base de données dédié et limité à la base de la boutique, pas un compte administrateur. Accordez les privilèges nécessaires à l’exécution et à la maintenance réelles. Évitez les privilèges globaux, FILE ou administratifs inutiles. Restreignez l’accès réseau à la base et utilisez une connexion privée lorsqu’elle est distante.

Protégez ou supprimez les outils publics d’administration de base de données. Préférez une voie privée authentifiée ou un tunnel SSH et désactivez les connexions web root ou sans mot de passe. Un préfixe de table différent ne corrige pas une injection SQL.

Supprimez le dossier install après l’installation et vérifiez qu’il n’est pas revenu après une migration ou une restauration : un installeur accessible permet à n’importe qui de relancer l’installation et de prendre le contrôle de la boutique. En avril 2026, Sansec a trouvé plus de 200 boutiques PrestaShop avec un installeur exposé.

Accès Webservice, partenaires logistiques et départs

Sous Paramètres avancés > Webservice, désactivez l’API si elle est inutilisée. Sinon, émettez une clé distincte par intégration, restreignez les ressources et méthodes, exigez HTTPS, stockez les secrets de manière sûre et révoquez les clés inutilisées. Examinez séparément les clients et périmètres Admin API là où elle est déployée.

Construisez la liste d’accès d’un prestataire 3PL à partir de ses requêtes réelles. Les commandes contiennent des identifiants d’adresses ; l’expédition peut donc nécessiter les données d’adresse, pays, état, transporteur et contact, en plus des commandes et de leurs détails. N’accordez que ce dont le workflow a besoin.

Les permissions de ressources n’isolent pas les champs ni les commandes individuellement. Les détails de commande peuvent révéler des champs de coût d’achat. Une liste d’affichage choisie par le client API n’est pas une frontière d’accès. Si un partenaire ne doit pas voir les coûts ou les commandes sans rapport, exposez un point d’entrée ou un export filtré contrôlé côté serveur.

Les mises à jour de suivi et les changements d’état de commande utilisent des circuits distincts. La création d’une ressource order_histories change l’état ; ajoutez sendemail=1 pour demander son email de statut configuré. L’état doit aussi avoir l’email activé et un modèle adapté. La mise à jour d’une ressource order_carriers change le suivi ; son option distincte sendemail=1 demande le message de transit, qui nécessite aussi une URL de suivi transporteur. Les deux options n’envoient aucun email par défaut. Mettez à jour le suivi avant de demander le message correspondant et dédupliquez les nouvelles tentatives.

1. Désactivez immédiatement le compte employé de la personne partante quand son accès prend fin.
2. Révoquez ses clés Webservice individuelles, clients API et accès à l’hébergement, SFTP, SSH, email et services tiers.
3. Invalidez les sessions et renouvelez les secrets partagés qu’elle connaissait.
4. Préservez les attributions utiles dans les commandes et les audits.
5. Examinez les tâches planifiées, les responsabilités et les contacts de récupération.

Un Profil est un rôle de permissions réutilisable, pas une connexion avec un interrupteur d’activation. Modifier ou supprimer un Profil partagé peut affecter d’autres employés. Consultez le guide Webservice pour les concepts API.

Exemple : transmission à un entrepôt

Supposons qu'un entrepôt ait besoin des commandes payées et doive renvoyer le suivi, sans recevoir les coûts d'achat. Partez d'une commande de test et de la liste des requêtes réelles de l'entrepôt. Si les droits standard sur les ressources exposent des champs hors accord, filtrez dans votre intégration contrôlée côté serveur plutôt que de faire confiance aux champs d'affichage demandés par l'entrepôt.

Testez la transmission en préproduction avec capture des emails sortants dans une boîte de test. Récupérez les données convenues de commande et d'adresse, puis tentez d'obtenir les coûts d'achat et une commande sans rapport via l'accès partenaire ; aucune tentative ne doit divulguer les données exclues. Mettez à jour le suivi avant de demander les actions d'état et d'email convenues. Rejouez le même événement d'entrepôt et confirmez que la gestion des tentatives évite les doublons d'historique et de messages. Révoquez la clé de test de l'entrepôt et confirmez que la requête suivante échoue ; cela prouve que vous pouvez arrêter l'intégration autant que la démarrer.

Vérifier un départ au-delà de la suppression d'un nom

Après les étapes de départ ci-dessus, testez le refus de la session existante et d'une nouvelle connexion de l'ancien employé, ainsi que l'échec des accès API révoqués. Confirmez que les autres employés peuvent toujours travailler. Si une ancienne session reste utilisable, examinez les contrôles de session de la version ou de la couche d'accès plutôt que de supposer que le changement du statut employé l'a invalidée. Vérifiez que les emails de récupération, accès des tâches planifiées et destinations de sauvegarde relèvent désormais d'une personne responsable.

Recruter et déléguer avec des accès maîtrisés

Identifiez le point de blocage avant de recruter de l’aide. Examinez l’ancienneté des échanges de support ouverts, les délais entre paiement et expédition, les erreurs de stock, les demandes manquées et le travail qui s’arrête quand vous vous absentez. Mesurez la première réponse depuis les horodatages des messages ou un rapport de helpdesk ; la liste du cœur n’est pas un tableau de bord complet des délais de réponse.

Le chiffre d'affaires ou les mouvements bancaires seuls ne donnent pas la marge nette par commande. Utilisez le calcul ci-dessous pour comparer le coût complet de l'aide à la contribution supplémentaire que votre temps libéré peut réellement produire, en tenant compte de la saisonnalité.

Pour intégrer une personne, créez le rôle dans Équipe > Profils, configurez les Permissions, puis créez l'Employé avec ce profil et seulement les accès boutique pertinents. Testez le rôle en vous connectant comme cette personne, y compris les URL directes et actions des modules tiers. Masquer un menu ne suffit pas pour tester l'autorisation. Limitez fortement l'installation de modules, le Gestionnaire SQL et la gestion des employés. Installer un module permet d'introduire du PHP côté serveur : traitez ce droit comme un privilège de déploiement.

Documentez le processus des états de commande, les règles de retour et remboursement, les procédures de stock et l'escalade de l'assistance. Les Messages prédéfinis de commande se choisissent depuis une fiche commande. Les fils du Service client ont leur propre fonctionnement de signature et de réponse par défaut ; un catalogue partagé de réponses types nécessite une intégration d'assistance adaptée.

Gardez la stratégie produit, les choix de fournisseurs, l’orientation de la marque et la politique client sous une responsabilité clairement définie. Externalisez une exécution précise quand le niveau de qualité, la fréquence, le contexte requis et le coût le justifient. Comparez les frais de stockage, réception, préparation/emballage, expédition, retours et minimums d’un 3PL avec vos propres coûts.

Donnez aux prestataires un brief écrit, des exemples d’acceptation, un calendrier de communication et une propriété claire des ressources et identifiants. Réévaluez le travail récurrent des sous-traitants si la coordination devient un frein. Le statut d’emploi dépend des règles locales et de la relation réelle, pas d’un seuil d’heures hebdomadaires. Préférez les hooks, la décoration de services et les points d’extension de thème pris en charge avant de recourir exclusivement aux overrides historiques.

Choisir l'aide selon le point de blocage

Faites un calcul d'embauche avec vos propres données : estimez les commandes supplémentaires que la capacité libérée peut réellement traiter, puis multipliez par la contribution par commande après coûts produits, frais de paiement, préparation, retours attendus et autres coûts variables. Comparez cette contribution aux salaires ou honoraires, charges employeur, formation, supervision et outils sur la même période. Sans demande supplémentaire réaliste, il n'y a pas non plus de contribution à la croissance ; la justification repose alors sur la qualité du service, la continuité ou la charge de travail plutôt que sur des revenus supposés.

Pour un prestataire catalogue, par exemple, fournissez une correspondance CSV convenue et des lignes exemples avant d'accorder l'import. Validez les références produit, la langue et le périmètre boutique en préproduction, examinez les produits modifiés, puis approuvez l'import de production. Un photographe peut livrer des fichiers nommés par référence sans accès au back-office ; un livrable spécialisé n'exige pas automatiquement un accès boutique.

Filtrage du trafic et boutiques en attente de migration

Un WAF peut bloquer certaines requêtes d’exploitation, limiter les abus et protéger des routes coûteuses comme les URL de recherche à facettes. Testez les règles sur la navigation, la commande, les API et les callbacks des prestataires. Robots.txt est une indication aux robots, pas un contrôle d’accès. Les blocages par pays et bannissements IP peuvent affecter des clients légitimes, notamment derrière des réseaux partagés.

Quand un proxy protège la boutique, restreignez les ports web du serveur d’origine aux réseaux de proxy de confiance et aux voies de gestion nécessaires. Couvrez IPv4 et IPv6 et tenez les listes d’adresses à jour. Les enregistrements de messagerie et les anciens DNS peuvent révéler l’IP d’origine. Protégez les accès SSH, email et au panneau d’hébergement par des règles distinctes.

Les champs d’expression de limitation de débit de Cloudflare varient selon l’offre : Free fournit des champs fondés sur le chemin, Pro ajoute la correspondance sur la chaîne de requête, et Business ajoute les champs d’expression d’IP source et de user-agent. Le comptage par IP est une capacité distincte. Advanced Rate Limiting est une offre Enterprise séparée. Vérifiez la disponibilité actuelle avant de concevoir une règle contre un afflux sensible aux paramètres de requête.

Un CAPTCHA peut réduire les abus en boutique mais nécessite des tests d'accessibilité et d'échec. reCAPTCHA & hCaptcha Protection couvre les formulaires clients pris en charge ; suivez son aide pour la configuration.

Customer Extra Info (IP Ban) fournit des informations visiteurs et le blocage IP ; suivez son aide pour configurer le périmètre applicable.

Utiliser des contrôles compensatoires pendant la migration

Identifiez le composant vulnérable exact et l’avis correspondant. Une règle d’interception WAF externe est un correctif virtuel ; modifier le code source est un correctif direct ou un rétroportage. Suivez et testez chaque mesure temporaire et fixez une date de retrait liée au plan de mise à niveau.

Pour la chaîne d’attaque historique du cache MySQL de Smarty, vérifiez la version affectée et la correction amont. Dans 1.7.8, _PS_SMARTY_CACHING_TYPE_ est une constante PHP qui contrôle le chargement de la ressource de cache MySQL. Ce n’est pas un sélecteur de la page Performances. Vérifiez la ressource de cache effective à l’exécution après correction.

Examinez individuellement les anciens points d'entrée autonomes plutôt que de bloquer tout le PHP des modules. L'immutabilité des fichiers est un contrôle administrateur facultatif pour des fichiers inventoriés individuellement ; PrestaShop modifie légitimement certains fichiers de configuration. Documentez leur déverrouillage pour maintenance et leur reverrouillage ensuite.

Rendre le confinement temporaire vérifiable

Pour chaque règle temporaire ou correctif rétroporté, consignez le composant et la version installée concernés, l'avis de sécurité ou les preuves des journaux, la requête ou le chemin de code exact couvert, le responsable, le retour arrière et la dépendance de migration qui le supprimera. Un blocage général de mots suspects peut manquer des entrées encodées et refuser des recherches légitimes ; testez le chemin d'exploitation confirmé et les requêtes normales.

Par exemple, un ancien module de recherche peut nécessiter un correctif ciblé d'une requête vulnérable et une règle de trafic contre les requêtes coûteuses de robots. Ces contrôles traitent des problèmes distincts. Prouvez que la requête visée est refusée, que les filtres légitimes fonctionnent et que l'origine ne permet pas de contourner le proxy, puis conservez les résultats avec le plan de migration. Examinez les événements WAF observés avant le blocage effectif pour inclure notifications de paiement, robots utiles et trafic client dans la décision.

Surveillance et autocontrôle pratique

Surveillez les fichiers PHP, JavaScript et modèles nouveaux ou modifiés par comparaison à une référence de déploiement fiable. Protégez cette référence séparément, examinez les exclusions et planifiez de vrais scans et envois d’alertes pour une détection sans surveillance. Un scan manuel est une comparaison à un instant donné.

Comparez le cœur avec la même version propre et les fichiers des modules avec des paquets fiables. Examinez les comptes employés inexpliqués, paramètres de paiement modifiés, champs de commande inconnus et scripts inattendus. Les changements de fichiers peuvent aussi être des déploiements légitimes ; enquêtez plutôt que de supprimer automatiquement les correspondances.

Pour examiner les employés en lecture seule, remplacez le préfixe des tables si nécessaire :

SELECT id_employee, email, id_profile, active, last_connection_date
FROM ps_employee
ORDER BY id_employee DESC;

La table standard des employés ne possède pas de date_add. Un identifiant croissant peut aider à examiner des comptes inconnus, mais n’est pas un horodatage de création. last_connection_date n’est pas un champ d’ancienneté du compte.

Depuis la racine de la boutique, ces recherches en lecture seule identifient des fichiers à examiner :

find img upload download -type f -iname '*.php*' -print
find img upload download -type f \( -iname '*.phtml*' -o -iname '*.phar*' \) -print
find . -type f -name '*.php' -mtime -14 -print
find . -type f -name '*.js' -mtime -14 -print
find . -type f -name '*.php' -exec awk 'length($0)>5000 {print FILENAME ":" FNR}' {} +

Les longues lignes et les chaînes encodées peuvent être légitimes. Recoupez mtime, ctime, les horodatages de création disponibles, les journaux et les instantanés. Ctime est le dernier changement d’état de l’inode, pas la création initiale du fichier ; les changements de propriété et de mode peuvent le mettre à jour.

Surveillez le contenu de l’accueil, des pages représentatives du catalogue et la disponibilité du tunnel de commande, pas seulement HTTP 200. Vérifiez indépendamment le renouvellement des certificats. Confirmez que l’offre de surveillance choisie inclut les alertes de certificat et de temps de réponse, puis testez leur livraison vers un canal effectivement suivi.

Un autocontrôle doit couvrir versions logicielles, mises à jour des modules, employés, comparaisons de fichiers, restrictions de l'origine et sauvegarde restaurée. Un profil employé en lecture seule ne rend pas automatiquement chaque point de configuration tiers sûr pour un auditeur ; convenez explicitement des accès requis et du traitement des données. Utilisez un compte temporaire pour un audit externe, fournissez si possible un accès en lecture aux fichiers et journaux, puis supprimez le compte à la fin convenue. Le guide de préparation à l'audit aide à préparer cette passation.

Pour un premier examen local, Security Scan fournit gratuitement des constats priorisés et des étapes de correction manuelles. Son examen est en lecture seule et conserve les constats dans la boutique ; il ne bloque pas le trafic, ne corrige pas les fichiers et ne change pas les réglages. Les analyses planifiées et alertes critiques facilitent le suivi, mais un score ne prouve pas l'absence d'infection.

Transformer les constats en actions

Conservez chaque constat non résolu avec son emplacement, ses preuves, son responsable et l'action suivante. Un autocontrôle sans anomalie ne répond qu'aux vérifications réellement effectuées. Faites remonter les constats inexpliqués et répétez les contrôles pertinents après mise à niveau, changement de thème, nouvelle intégration ou passation d'accès.

Sauvegardes et réponse aux incidents

Sauvegardez la base et les fichiers correspondants selon un calendrier adapté à votre tolérance de perte de commandes. Gardez plusieurs points de restauration, chiffrez les archives sensibles et conservez une copie hors serveur avec des identifiants distincts. Définissez la rétention selon les exigences de restauration et d’activité plutôt qu’un nombre universel de jours.

Utilisez des identifiants de base protégés et un outil de sauvegarde qui vérifie les erreurs. Dans les commandes crontab en ligne, les signes de pourcentage exigent un échappement simple ; placer le processus de sauvegarde dans un script évite ce piège. Testez une restauration sur une boutique isolée, avec connexion client, images, commandes et configuration. Consultez le guide de sauvegarde.

En cas de compromission suspectée

1. Isolez la boutique au niveau d’un serveur ou proxy de confiance. Empêchez de nouveaux achats ou une nouvelle exposition de données tout en préservant l’accès des intervenants.
2. Préservez les preuves de l’incident : base, fichiers, journaux pertinents et horodatages. Stockez les copies de manière sûre avant tout nettoyage destructif.
3. Identifiez le point d’entrée et les mécanismes de persistance, notamment les comptes employés, tâches planifiées et contenus injectés en base.
4. Depuis un appareil et un environnement sains, révoquez les sessions et renouvelez les identifiants exposés d’hébergement, SSH, SFTP, base, employés, messagerie et paiement/API. Coordonnez les changements de configuration pour permettre la restauration.
5. Reconstruisez depuis des paquets logiciels fiables et restaurez des données saines, puis corrigez le point d’entrée. Ne réutilisez pas sans examen un thème compromis, une arborescence d’images compromise ou une base compromise.
6. Testez la commande, les paiements, remboursements, emails et intégrations avant réouverture. Surveillez attentivement toute récidive.

Si vous utilisez Apache pour renvoyer un statut de maintenance, configurez ErrorDocument 503 séparément. Une réécriture avec R=503 ne sert pas à elle seule la substitution comme page de maintenance.

Informez selon le cas votre hébergeur, prestataire de paiement et intervenants de sécurité. Selon l’article 33 du GDPR, notifiez l’autorité de contrôle sans retard injustifié et, si possible, dans les 72 heures après en avoir pris connaissance, sauf si un risque pour les personnes est peu probable. L’article 34 exige généralement d’informer sans retard injustifié les personnes concernées lorsqu’un risque élevé est probable, sous réserve de ses exceptions. Utilisez les recommandations de l’EDPB sur les violations et votre procédure de protection des données.

Avant la réouverture, confirmez que le débogage est désactivé, les outils temporaires supprimés, les points d’entrée vulnérables corrigés ou retirés, les identifiants et accès employés maîtrisés, les sauvegardes restaurables et les alertes reçues par la personne responsable.

Convenir à l'avance des décisions de reprise

Consignez qui peut autoriser le confinement, contacter l'hébergeur et le prestataire de paiement, récupérer les sauvegardes protégées et approuver la réouverture. Notez la tolérance de perte de commandes et l'interruption acceptable, puis mesurez une restauration isolée selon ces critères. Les sauvegardes peuvent contenir les mêmes fichiers malveillants ou données injectées que la production ; le choix du point de restauration exige donc des preuves du début de l'intrusion.

Examinez les données personnelles conservées par la boutique, les modules, exports et journaux. Supprimez les copies inutiles selon une procédure de conservation convenue et limitez l'accès aux autres. Collecter davantage de données sans besoin métier augmente ce qu'un attaquant peut obtenir ; leur copie en préproduction ou dans une archive d'incident nécessite aussi un accès contrôlé.

Questions à poser à votre développeur ou agence

• Quel composant et quelle version exacts sont exposés, et quelles preuves relient le changement proposé à cette exposition ?
• Quels contrôles relèvent de l'hébergeur, du proxy, de la boutique ou d'un module, et qui les maintient après la passation ?
• Quelles fonctions du thème, parcours de paiement, marchés et intégrations partenaires existants ont été testés en préproduction, y compris les actions refusées et la reprise ?
• Quelle est la procédure de bascule et de retour arrière, et comment rapprocher les commandes ou paiements reçus pendant une migration ?
• Où sont la référence de déploiement, les résultats de restauration et les preuves d'envoi d'alertes, et qui intervient lorsqu'un contrôle échoue ?
• Quelles règles temporaires, quels accès et outils doivent être supprimés, et quels travaux correctifs restent hors de l'évaluation convenue ?

Questions des commerçants

L'hébergement infogéré assure-t-il la sécurité de la boutique ?

Demandez par écrit le périmètre de maintenance. La maintenance du système d'exploitation et du serveur ne dit pas qui met à jour PrestaShop, le thème ou les modules. Confirmez qui examine les avis, approuve les changements et répond aux alertes applicatives selon votre contrat réel.

Et si mon équipe ne peut pas utiliser des IP fixes de bureau ?

Évaluez une sortie VPN gérée ou un proxy d'accès fondé sur l'identité avec authentification individuelle. Testez les lieux de travail réels et la récupération en cas d'appareil perdu avant de l'imposer. Conservez une voie de récupération approuvée plutôt que d'élargir la liste autorisée à chaque déplacement.

Faut-il installer immédiatement un scanner si je soupçonne une intrusion ?

Convenez d'abord de la méthode d'examen avec l'intervenant. Installer un logiciel modifie les fichiers et peut altérer des preuves utiles ou la référence à comparer. Préservez l'état affecté et organisez l'inspection depuis un environnement de confiance avant d'ajouter des outils sur une installation suspectée compromise.

Comment transmettre des journaux ou accès à une personne qui m'aide ?

Convenez d'un canal de transfert protégé et fournissez seulement le nécessaire à l'enquête. Expurgez les données personnelles sans rapport et les secrets des captures et pièces jointes courantes ; si un journal original est nécessaire comme preuve, préservez-le séparément sous accès contrôlé. Utilisez un accès individuel temporaire plutôt que de coller un mot de passe propriétaire partagé dans un ticket.

Les règles temporaires peuvent-elles rester après migration ?

Réexaminez chaque règle selon l'exposition réelle de la boutique migrée. Supprimez les exceptions obsolètes et ne retirez une mesure compensatoire qu'après avoir prouvé que le chemin vulnérable est corrigé ou supprimé. Conservez les défenses et surveillances utiles dont l'objectif reste documenté.