Les mots qu'on emploie quand on parle de la sécurité de votre boutique, expliqués sans jargon. Chaque terme a son ancre : les autres pages du site pointent directement ici.
Une erreur dans du code qui permet de lui faire faire ce qu'il ne devrait pas.
Une faille n'est pas un virus : c'est un défaut de conception ou de programmation, le plus souvent un contrôle oublié sur une donnée reçue de l'extérieur. Tant que personne ne l'utilise, elle ne fait rien. Le danger apparaît quand quelqu'un écrit le moyen de s'en servir — c'est l'exploit. Sur PrestaShop, l'immense majorité des failles exploitées ne sont pas dans le cœur mais dans les modules tiers.
Le mode d'emploi qui transforme une faille en intrusion réelle.
Le bout de code ou la séquence de requêtes qui exploite concrètement une faille. C'est ce qui fait passer un problème théorique à un problème qui vous coûte de l'argent : une faille sans exploit connu reste dormante, une faille avec exploit public est balayée par des robots en quelques heures. C'est pourquoi le délai entre la publication d'une faille et la mise à jour de votre boutique compte autant.
Une faille exploitée alors qu'aucun correctif n'existe encore.
Le cas le plus inconfortable : les attaques ont commencé et l'éditeur du module n'a pas encore publié de mise à jour — parfois il n'en publiera jamais, notamment sur un module abandonné. Mettre à jour ne sert alors à rien puisqu'il n'y a rien à installer. C'est précisément ce que couvre un pare-feu applicatif : il refuse la requête d'attaque en amont, ce qui protège immédiatement, sans attendre un correctif qui n'existe pas.
Un accès caché laissé par l'attaquant pour revenir quand il veut.
Un fichier discret déposé sur votre serveur, souvent dans un dossier banal comme /upload, /img ou /cache, qui permet à l'attaquant de reprendre la main sur la boutique même après que vous ayez changé tous vos mots de passe. C'est la raison pour laquelle « j'ai changé mon mot de passe admin » ne suffit jamais à régler un piratage : tant que la porte dérobée est là, elle reste ouverte. Un nettoyage sérieux consiste d'abord à les trouver toutes.
Une backdoor pilotable depuis un navigateur, comme un panneau d'administration pirate.
Une forme de porte dérobée qui offre à l'attaquant une véritable interface : parcourir vos fichiers, en téléverser, exécuter des commandes sur le serveur, se connecter à votre base de données. Les webshells se déguisent volontiers en fichier légitime — un nom qui ressemble à un fichier PrestaShop, ou du code caché à la fin d'une image.
Du code injecté dans la page de paiement qui recopie les numéros de carte de vos clients.
Quelques lignes de JavaScript ajoutées à votre tunnel de commande. Le client paie normalement, la commande passe normalement, et en parallèle son numéro de carte part chez l'attaquant. Rien ne se voit à l'œil nu, ni pour vous ni pour l'acheteur — c'est souvent la banque ou un client qui vous alerte, des semaines plus tard. C'est le type d'infection le plus coûteux : au-delà de la fraude, votre responsabilité RGPD est engagée.
Terme générique pour tout code déposé sur votre site sans votre accord.
Le mot couvre aussi bien une porte dérobée qu'un script de redirection, un mineur de cryptomonnaie ou un relais de spam. Sur PrestaShop, il arrive presque toujours par le même chemin : un module tiers dont la faille n'a pas été corrigée.
Vos fichiers ou votre base rendus illisibles, et une rançon réclamée pour les récupérer.
Sur une boutique, l'attaque prend rarement la forme du chiffrement spectaculaire qu'on voit sur les postes de bureau : le plus souvent, l'attaquant chiffre ou efface la base de données et les fichiers, puis laisse une note réclamant un paiement. La seule défense qui fonctionne vraiment est une sauvegarde externalisée que vous avez déjà testée en restauration — pas une sauvegarde qui vit sur le même serveur, car elle est chiffrée en même temps que le reste. Payer ne garantit rien et finance l'attaque suivante.
Détourner un formulaire ou une URL pour faire parler votre base de données.
L'attaquant glisse un morceau de requête dans un champ de recherche, un filtre ou un paramètre d'URL. Si le module ne vérifie pas correctement ce qu'il reçoit, la base exécute la requête : lecture des comptes clients, des commandes, parfois création d'un compte administrateur. C'est la faille la plus répandue sur les modules PrestaShop tiers.
Faire exécuter du code de l'attaquant dans le navigateur de vos visiteurs.
L'attaquant place un script dans une zone que votre boutique réaffiche telle quelle — un avis produit, un nom, un paramètre d'URL. Le script s'exécute ensuite chez chaque visiteur qui voit la page : vol de session, redirection, ou pose d'un skimmer sur la page de paiement.
Essayer des milliers de mots de passe jusqu'à tomber sur le bon.
Des robots testent en boucle des combinaisons identifiant/mot de passe sur votre page de connexion administrateur. Sans limitation, un mot de passe faible tombe en quelques heures. Au-delà du risque d'intrusion, ces vagues de tentatives ralentissent le serveur et font parfois tomber la boutique à elles seules.
Un faux message qui vous fait saisir vos identifiants sur une page imitant la vraie.
Un courriel ou un SMS qui se fait passer pour votre hébergeur, pour PrestaShop, pour votre prestataire de paiement — ou pour votre propre back-office — et vous invite à « vous reconnecter ». Le mot de passe saisi part chez l'attaquant, qui entre ensuite par la porte principale : aucune faille technique n'est nécessaire, ce qui explique qu'un pare-feu seul ne suffise pas. C'est la raison d'être du contrôle des connexions depuis une adresse inhabituelle. À noter : les pirates hameçonnent aussi vos clients, en utilisant les données volées dans une boutique compromise pour rendre le message crédible.
Faire lire au site un fichier qu'il n'aurait jamais dû ouvrir.
En manipulant un paramètre qui désigne un fichier, l'attaquant remonte l'arborescence du serveur et fait afficher un fichier sensible — typiquement votre parameters.php, qui contient les identifiants de la base de données. Dans les cas les plus graves, la faille permet aussi de faire exécuter un fichier déposé au préalable.
Montrer une page propre à vous, et une page piratée aux autres.
Le code malveillant regarde qui demande la page. Un visiteur venu de Google est redirigé vers du spam ou du phishing ; vous, connecté depuis votre adresse habituelle, ne voyez rien d'anormal. C'est pour cela qu'un piratage peut durer des semaines sans que le commerçant s'en aperçoive, jusqu'à ce que le trafic s'effondre.
Votre page d'accueil remplacée par un message de l'attaquant.
La forme la plus visible d'un piratage : la boutique disparaît derrière une page revendiquée par un groupe. Paradoxalement c'est la moins grave — elle se voit immédiatement, donc elle se traite vite. Les infections qui coûtent cher sont celles qui prennent soin de ne rien changer à l'apparence du site. Un défacement reste un signal sérieux : si quelqu'un a pu réécrire votre page d'accueil, il a eu accès à tout le reste.
Votre serveur détourné pour envoyer des emails à la place de l'attaquant.
Un script déposé sur le site envoie des milliers d'emails frauduleux depuis votre serveur. Conséquences immédiates : votre domaine est blacklisté par les fournisseurs de messagerie (vos vraies commandes n'arrivent plus), et votre hébergeur finit par suspendre le compte.
Personne ne vous a choisi : des robots frappent à toutes les portes, en permanence.
« Pourquoi ma boutique ? Je ne suis pas Amazon. » Parce qu'aucun humain ne vous a visé. Des réseaux de machines compromises parcourent Internet en continu et testent sur chaque site la liste des failles publiées, sans distinction de taille ni de chiffre d'affaires. Une petite boutique avec un module non mis à jour est une cible aussi valable qu'une grande — souvent plus, parce qu'elle est moins surveillée. C'est aussi ce qui rend la liste noire partagée efficace : ce sont les mêmes adresses qui frappent partout.
Un filtre qui bloque les requêtes hostiles avant qu'elles n'atteignent votre boutique.
Là où un antivirus regarde vos fichiers, le pare-feu applicatif regarde le trafic entrant et refuse ce qui ressemble à une attaque : injection SQL, script injecté, tentative de connexion en masse. Son intérêt principal, c'est le temps : il protège une faille connue immédiatement, sans attendre que l'éditeur du module publie un correctif.
L'identifiant public d'une faille de sécurité connue.
Quand une faille est découverte dans PrestaShop ou dans un module, elle reçoit un numéro de référence mondial, par exemple CVE-2024-6648. Ce numéro est public : les attaquants s'en servent comme d'un catalogue et scannent Internet à la recherche des boutiques qui n'ont pas encore mis à jour. C'est la course entre le moment où la faille est publiée et le moment où vous corrigez.
La fiche qui décrit une faille : module touché, versions concernées, correctif.
Pour chaque faille suivie, nous tenons une fiche : quel module, quelles versions sont vulnérables, à partir de quelle version c'est corrigé, et ce que nous faisons en attendant. Votre tableau de bord croise ces fiches avec les modules réellement installés sur votre boutique, pour ne vous montrer que ce qui vous concerne.
Comparer chacun de vos fichiers à l'original officiel PrestaShop.
Chaque fichier possède une empreinte numérique unique. En comparant l'empreinte de vos fichiers à celle des fichiers officiels de votre version de PrestaShop, on repère au fichier près ce qui a été modifié, ajouté ou supprimé — même si le code injecté est trop bien écrit pour ressembler à un virus.
Une attaque bloquée chez un client protège immédiatement tous les autres.
Quand une adresse IP attaque une boutique du réseau, elle est ajoutée à une liste partagée par l'ensemble des boutiques protégées. Le même attaquant qui se présente ensuite chez vous est refusé avant même d'avoir essayé. Plus le réseau compte de boutiques, plus la liste est à jour.
Un second facteur en plus du mot de passe, pour qu'un mot de passe volé ne suffise plus.
Un code à usage unique demandé en plus du mot de passe au moment de la connexion. C'est la seule protection réellement efficace contre l'hameçonnage et le vol d'identifiants : même avec le bon mot de passe, l'attaquant est arrêté. Le même principe s'applique au contrôle des connexions administrateur depuis une adresse que la boutique n'a jamais utilisée : une preuve supplémentaire est exigée avant de laisser entrer.
Un fichier signalé comme suspect alors qu'il est parfaitement légitime.
Certains modules du commerce écrivent du code compressé ou encodé qui ressemble, de loin, à du code malveillant. Un bon antivirus doit le signaler plutôt que de l'ignorer, mais il doit aussi permettre de trancher vite. Le tableau de bord vous donne le contexte et l'extrait de code exact pour décider — et notre équipe arbitre les cas douteux.
Fermer les portes inutiles pour réduire ce qu'un attaquant peut atteindre.
L'ensemble des réglages qui rendent une intrusion plus difficile et moins profitable : permissions de fichiers correctes, version de PHP maintenue, accès administrateur restreint, dossiers d'installation supprimés. Ce n'est pas une protection contre une attaque en particulier, c'est ce qui fait qu'une faille exploitée cause moins de dégâts.
L'écran rouge « Site dangereux » qui coupe votre trafic.
Quand Google détecte du contenu malveillant sur une boutique, il affiche un avertissement plein écran avant de laisser entrer le visiteur, et fait chuter le référencement. Le retrait n'est pas automatique : il faut nettoyer, puis demander un réexamen dans la Search Console. Comptez 24 à 72 heures après validation.
Refermer une faille sans changer de version du module.
Quand une faille est publiée, la réponse normale est de mettre à jour le module — encore faut-il que l'éditeur ait publié une version corrigée, qu'elle soit compatible avec votre boutique et que vous puissiez l'installer. Un correctif agit autrement : il modifie précisément les lignes fautives dans la version que vous avez déjà. La faille se referme sans changement de version, sans risque de régression sur votre thème, et l'opération est réversible.
Prévenir l'éditeur d'abord, publier le détail ensuite — ou jamais.
Publier le détail d'une faille avant que l'éditeur ne l'ait corrigée arme n'importe qui contre toutes les boutiques qui utilisent le module concerné. La divulgation coordonnée consiste à prévenir l'éditeur, à lui laisser le temps de livrer un correctif, et à ne publier qu'ensuite. C'est pourquoi nous comptons publiquement nos propres découvertes sans jamais nommer le module tant que la correction n'est pas disponible pour tout le monde.
Un terme vous manque, ou une définition n'est pas claire ? Dites-le nous, on complète.
