Le problème à résoudre
Une boutique concentre comptes clients, données de commande, modules tiers et connexions de paiement. La sécurité doit préserver à la fois confidentialité, intégrité des prix et disponibilité du parcours de commande.
Commencez par l’inventaire : version, modules, comptes administrateurs, accès serveur, webhooks, tâches et prestataires. Ce qui n’est pas identifié ne peut pas être corrigé proprement.
Reconnaître les bons signaux
| Signal observé | Interprétation probable | Premier contrôle |
|---|---|---|
| Fichier modifié récemment | Mise à jour ou compromission | Comparer à une source fiable |
| Compte admin inconnu | Accès non maîtrisé | Suspendre et enquêter |
| Redirection au paiement | Module ou injection | Isoler la boutique |
Les notions à maîtriser
- Les modules et thèmes doivent provenir de sources connues et rester maintenus.
- Le back-office nécessite MFA lorsque disponible, comptes nominatifs et restriction d’accès adaptée.
- Le serveur ne doit pas permettre l’écriture partout par le processus web.
- Les données de paiement doivent rester chez un prestataire conforme plutôt que transiter inutilement par le site.
Méthode de diagnostic
Plan d’action recommandé
- Mettre à jour sur préproduction avec un test de commande complet.
- Retirer modules inactifs et comptes devenus inutiles.
- Appliquer moindre privilège aux fichiers, base et accès humains.
- Ajouter surveillance des fichiers, erreurs, connexions et changements admin.
- Préparer un plan d’incident incluant paiement, clients et preuves.
Relevé de fichiers à examiner
Depuis la racine de la boutique, ces recherches recensent les fichiers récemment modifiés et ceux accessibles en écriture à tous. Elles ne prouvent pas une compromission : chaque résultat doit être expliqué.
find . -type f -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
find . -type f -perm -0002 -printExcluez les dossiers de cache si le volume masque les éléments utiles. En cas de suspicion, préservez d’abord les journaux et une copie des fichiers avant toute suppression.
Erreurs fréquentes à éviter
- Modifier les fichiers suspects avant d’en conserver une copie d’analyse.
- Partager un compte super-admin entre plusieurs intervenants.
- Bloquer toutes les requêtes automatiques sans tester webhooks et prestataires.
Indicateurs à suivre
| Indicateur | Repère | Pourquoi le suivre |
|---|---|---|
| Correctifs | Appliqués dans une fenêtre définie | Réduit l’exposition |
| Comptes admin | Nominatifs et revus | Assure la traçabilité |
| Intégrité | Écarts expliqués | Détecte les modifications |
Checklist avant validation
- Une mesure de référence est conservée.
- Le changement est testé hors production lorsque c’est possible.
- Une sauvegarde ou un retour arrière est disponible.
- Les dépendances web, e-mail et DNS ont été contrôlées.
- Les journaux et alertes sont surveillés après intervention.
- Le résultat est documenté avec date et responsable.
Questions fréquentes
Le changement d’URL admin suffit-il ?
Non. C’est une réduction de bruit, pas un remplacement des correctifs et contrôles d’accès.
Que faire en cas de suspicion ?
Isoler si nécessaire, préserver les journaux, révoquer les accès et restaurer seulement après avoir compris la cause.
Faut-il un WAF ?
Il peut filtrer des attaques connues, mais ne corrige ni un module vulnérable ni un compte compromis.
Sources techniques
Pour vérifier les règles et approfondir le sujet :
Besoin de sécuriser une boutique PrestaShop ?
L’intervention doit couvrir application, accès, serveur, sauvegardes et réponse à incident.
Voir l’accompagnement sécurité