Sécuriser PrestaShop en 2025 ne se résume plus à quelques gestes symboliques comme activer le HTTPS, changer régulièrement son mot de passe (de complexité forte) ou encore ajouter une double authentification.

Les attaquants s'adaptent. Les menaces évoluent. Et la plupart des standards, bien qu'utiles, ont toujours 2 à 5 ans de retard sur la réalité du terrain.

Cet article s'adresse aux marchands ancrés dans le réel, qui veulent protéger PrestaShop professionnellement face aux risques concrets : vols de données clients, compromission de modules, détournements de paiements ou d'API, etc.

📌 Si vous en êtes encore à vous demander s'il faut activer le HTTPS, ne pas utiliser le même mot de passe partout ou si la MFA est utile, cet article ne vous est pas destiné :
- Nous vous invitons d'abord à vous renseigner sur les déclarations sur l'honneur que vous avez signées auprès de votre banque dans le cadre de votre contrat de vente à distance (notamment la conformité SAQ-A, a minima).
- Une fois vos obligations légales effectivement remplies sur les prérequis attendus depuis plus de 5 ans, vous pourrez revenir à cette lecture et entrer dans le cœur du sujet : la sécurisation professionnelle d'une boutique PrestaShop face aux menaces actuelles.

💡 Etat de la menace en 2025

En 2025, les cybermenaces ciblant les sites E-Commerces ne relèvent plus de la fiction ni de l'attaque opportuniste. Elles sont industrialisées, souvent silencieuses et parfaitement intégrées aux logiques métier par les cybercriminels.

Pour des raisons d'accessibilité, nous avons choisi de nous concentrer uniquement sur des menaces de niveau junior et confirmé. Un second article dédié aux menaces de niveau senior paraîtra; nous y aborderons notamment les attaques reposant sur des chaînes de vulnérabilités (dont CWE-79 T2 et CWE-502 variante phar).

🎯 Menace 1 - Webskimmers : vos tunnels de paiement réécrits pour piller les cartes bleues

Les attaques les plus rentables aujourd'hui sont celles des webskimmers, qui consistent à réécrire le programme du tunnel d'achat pour le détourner au plus bas niveau possible.

L'objectif : supprimer les moyens de paiement légitimes (ex : CB, PayPal, Stripe, ...) pour les remplacer par des formulaires contrôlés par l'attaquant, et intercepter les données de carte bancaire en temps réel.

Pour maximiser la durée du vol de cartes bleues, ces formulaires malicieux sont invisibles pour les administrateurs grâce à un contrôle des cookies, et vos clients ne les voient qu'une fois sur deux.

La première fois, ils se font voler leur carte bancaire. Celle-ci sera revendue plusieurs semaines ou mois plus tard à une dizaine d'euros sur le darknet, puis le vrai moyen de paiement s'affiche.

Vous recevez l'argent, le client est débité normalement, puis livré tout aussi normalement. Tout semble parfaitement fonctionner.

L'objectif des criminels est de rester sous les radars le plus longtemps possible.

Contrairement aux webskimmers historiques (aussi appelés Magecart – pour les paniers Magento, apparus sur l'écosystème Magento courant 2017), ces webskimmers modernes sont implantés côté serveur.

Résultat :

Ils échappent aux CSP (Content Security Policy)
Le marchand continue d'encaisser sans voir que les données sensibles sont exfiltrées.
L'utilisateur ne se doute de rien jusqu'au débit frauduleux, plusieurs semaines ou mois plus tard quand sa CB aura été revendue 10€ sur le darkweb (prix moyen constaté).

Voici à quoi cela peut ressembler dans votre tunnel d'achat - les webskimmers les plus sophistiqués sont personnalisés aux couleurs de votre banque :

Webskimmer - altération malveillante du programme des tunnels d'achat de site E-Commerce

🕵️ Menace 2 - Infostealers : pillage complet - login / mot de passe et cartes bleues

En parallèle, une autre menace se développe : les infostealers déployés côté serveur, comme SoftbyLinux et ses forks dont SoftwareByMS.

Ce malware précis infecte le titre des sites PrestaShop (balise HTML title), généralement via des modules souffrant d'injections SQL, tous les shops piratés sont donc indexés dans les SERP (Google / Bing).

Vous pouvez le constater en recherchant ces mots clés sur Google et Bing :

Ces malwares collectent en temps réel tout ce que les visiteurs des sites Internet saisissent : login / mot de passe / adresse complète / email / téléphone et évidemment les cartes bleues, puis les transfèrent automatiquement vers un serveur sous contrôle d'un réseau criminel.

🚨 Menace 3 – Les fuites de données générées par les builders

Les éditeurs visuels (builders) intégrés comme Iquit Elementor, Creative Elements, etc., facilitent la mise en page, mais ouvrent aussi la porte à des fuites de données sensibles.

Il n'est pas rare que des marchands, sans le réaliser, insèrent dans des contenus publics (fiches produits, pages CMS, sliders) des clés secrètes (token) lors de glissé-déposé malencontreux depuis leur backoffice.

Un clic long sur un élément visuel tel qu'un bouton du BO et un relâchement du clic dans la zone texte suffit à réaliser ce glissé-déposé non souhaité.

Ces données sont ensuite exposées publiquement sur le site, parfois indexées par Google ou aspirées par des robots.

En soi, ces tokens ne donnent pas accès direct à un compte, mais ils peuvent parfois être exploités dans des attaques de type CSRF (Cross-Site Request Forgery), notamment pour cibler les administrateurs connectés - lesquels sont souvent en liste blanche.

Le scénario type : un lien malveillant inséré dans un mail ou dans une ressource externe exécute une action privilégiée (suppression, désactivation, exfiltration de données) via une requête forgée à l'aide d'un token public exposé sur le site.

Ce type d'exposition est discret : il n'y a ni alerte, ni compromission visible, et la faille reste active tant que le contenu contenant la clé n'est pas modifié.

Ces fuites sont difficiles à détecter et ne relèvent pas d'une vulnérabilité technique, mais d'un défaut de conception des interfaces utilisateur. Elles sont pourtant à l'origine d'attaques silencieuses et impactantes.

Puisque ces fuites sont dans les pages, elles sont souvent indexées dans les SERP (Google / Bing / Public WWW), vous pouvez donc les suivre via ces mots clés :

🔐 Menace 4 – Détournement de clés d'API : vol ou injection silencieuse

Dans PrestaShop, les clés d'API sont souvent la porte d'entrée vers les données les plus sensibles du système : commandes et clients.

Nous vous prions de partir du principe que le propos qui suit va bien au-delà de l'écosystème PrestaShop - il concerne la quasi totalité des écosystèmes E-Commerce incluant des solutions SaaS bien connues.

📥 Vol de clé existante (accès légitime)

Il n'est même pas nécessaire de pirater le système : dans une grande majorité des cas, il suffit d'un accès au backoffice, et de quelques secondes pour se rendre dans le menu dédié aux webservices (menu Paramètres avancés > Webservice) et copier-coller une clé API existante - si nécessaire en changeant sensiblement ses droits.

Cette clé, une fois exfiltrée, permet à un attaquant de :

extraire les clients / commandes (endpoint /api/customers et /api/orders),
extraire ou manipuler des configurations sensibles (endpoint /api/configurations) dont des clés externes vers des API bancaires,
ajouter des super-administrateurs (endpoint /api/employees), récupérer des mots de passes (chiffrés sans grain de sel depuis PS 1.7),
de faire n'importe quoi dans le périmètre configuré de la clé.

Aucun besoin de mot de passe, ni d'authentification : la clé suffit.

Pour bien comprendre la simplicité de cette attaque qui repose sur quatre clics de souris dès qu'un accès au BO est octroyé, voici quelques captures d'écrans :

1. Accédez à la page des Webservices : Paramètres avancés > Webservice, puis copiez-collez l'une des clés affichées :

2. Cliquez sur la clé et modifiez ses droits pour lui donner accès aux configurations de PrestaShop :

3. Vous venez d'obtenir les droits nécessaires pour exfiltrer toutes les données de configuration critiques du Shop - incluant, dans certains cas, les accès complets à des services externes comme des API bancaires.

Vous pouvez simplement y accéder via ce lien https://www.test.fr/api/configurations?display=full&ws_key=votre_clé

🧨 Injection ou création malveillante de clé (accès détourné)

Dans d'autres cas, l'attaque ne repose pas sur une clé existante, mais sur la création d'une nouvelle clé, de manière furtive.

Cela peut se produire :

via un accès backoffice compromis, utilisé par un administrateur malveillant ou une session détournée (ne désactivez pas le contrôle IP/Cookie dans Paramètres avancés > Administration) ;
ou via une injection SQL dans un module vulnérable, permettant d'insérer une clé active dans la base sans passer par l'interface.

Dans les deux cas, la clé semble “légitime” aux yeux du système, et permet un accès complet aux webservices - sans jamais déclencher d'alerte, puisque les appels passent par des points officiellement autorisés.

🛡️ Ces attaques sont d'autant plus dangereuses qu'elles sont difficiles à détecter et persistantes. Une clé mal utilisée avec parcimonie peut rester active plusieurs mois avant d'être repérée.

🛡️ Passer à l'action : sécuriser PrestaShop professionnellement

Identifier les menaces, c'est une première étape. Mais cela ne protège de rien tant qu'aucune mesure concrète n'est mise en œuvre.

La sécurisation d'un site PrestaShop ne repose ni sur la chance, ni sur des cases à cocher dans un backoffice. Elle repose sur une démarche professionnelle, rigoureuse, continue - à la hauteur des attaques modernes décrites précédemment.

Voici une sélection de pratiques, méthodes et outils concrets à mettre en œuvre pour reprendre le contrôle et réduire drastiquement votre surface d'attaque.

💡 Solutions pour les menaces 1 et 2 : webskimmers / infostealers

Pour adresser ces menaces, partons du principe que vous appartenez certainement à l'une de ces deux catégories de marchands :

✅ Vous ne mettez jamais à jour vos modules car "tout fonctionne", ou parce que chaque mise à jour est un risque ou une perte de temps.
✅ Vous êtes dépendant d'éditeurs qui ne publient jamais leurs vulnérabilités (voir l'article : Pourquoi Prestashop hack - Pourquoi de nombreux concepteurs ne respectent pas l'état de l'Art)

Si vous vous reconnaissez dans l'une de ces deux situations (ce qui est le cas de 98 % des marchands audités par TouchWeb), alors vous êtes exposé en permanence, même si votre backoffice est verrouillé.

En effet, la grande majorité des compromissions récentes ne proviennent pas d'une faille PrestaShop, mais d'un module vulnérable souvent activement exploité dans la nature sans que le marchand en soit informé.

Si vous avez fait la rencontre de réseaux criminels professionnels gravitant sur les Shop à plus d'un million d'euros par an, vous avez probablement constaté avec désarroi que votre antivirus PrestaShop, antimalware ou FIM n'avait rien détecté.

Dans un premier temps, nous vous invitons à choisir avec soin les éditeurs avec lesquels vous travaillez. Il est essentiel, pour la sécurité de votre PrestaShop, de collaborer avec des éditeurs ayant une politique de sécurité publique, s'engageant à publier leurs vulnérabilités – seul moyen professionnel et responsable de communication en la matière.

Pour simplifier vos démarches, nous vous recommandons de privilégier les éditeurs adhérents à notre charte de cybersécurité PrestaShop responsable. Nous nous sommes assurés qu'ils respectent au mieux les exigences de votre projet. Vous pouvez les identifier facilement grâce à ce badge :

Dans un deuxième temps, nous vous conseillons de :

Déployer des mesures de sécurité préventive via un WAF professionnel adapté à PrestaShop et si possible un IPS (article à venir)
Bénéficier d'une sauvegarde PrestaShop professionnelle résistante à un large éventail de menace (multi-site avec glacier air-gapped)
Placer sous restriction par adresse IP toutes les zones sensibles incluant vos interfaces d'administration (BO), les systèmes de gestion de vos bases de données (PHPMyAdmin / Adminer) et les accès FTP / SSH
Surveiller de manière continue que ces adresses IP sont (toujours) bien légitimes à outrepasser vos restrictions.
Si la restriction par adresse IP n'est pas possible, vous devez être alerté dès qu'une adresse IP inconnue accède à une zone sensible et réclamer des justifications aux concernés - la majorité des marchands acceptera rapidement le principe de la restriction IP quand ils prendront la mesure de leur manque de maîtrise.

Vous pouvez rapidement contrôler votre exposition à l'infostealer SoftByLlinux et ses clones en stressant rapidement votre WAF via sa charge primordiale usuelle sur la classe de vulnérabilités (CWE) la plus probable (une injection SQL - CWE-89) :

SET @a = X'5345542040747066203D202873656C656374206C656674287461626C655F6E616D65202C204C4F434154452827636F6E66696775726174696F6E272C207461626C655F6E616D65292D31292066726F6D20696E666F726D6174696F6E5F736368656D612E7461626C6573207768657265207461626C655F736368656D61203D202873656C65637420646174616261736528292920616E64207461626C655F6E616D65206C696B65202725636F6E66696775726174696F6E27204F52444552204259204C454E475448287461626C655F6E616D652920415343204C494D49542031293B';PREPARE stmt FROM @a;EXECUTE stmt;SET @b = 0x534554204063203D20434F4E434154282755504441544520272C407470662C27636F6E66696775726174696F6E205345542076616C75653D434F4E4341542876616C75652C223C7363726970743E616C65727428537472696E672E66726F6D436F6465506F696E74283078323736342C2030784645304629293B3C2F7363726970743E2229205748455245206E616D653D2250535F53484F505F4E414D45222729;PREPARE stmt2 FROM @b;EXECUTE stmt2;PREPARE stmt3 FROM @c;EXECUTE stmt3;

Cette triple injection SQL imbriquée est une charge auto-adaptative qui précalcule le préfixe aléatoire de la base de données pour pouvoir être injectée n'importe où. N'oubliez pas de stresser tous les vecteurs d'appels : en GET / POST / JSON / XML / COOKIE / HEADER HTTP / UPLOAD etc.

⚠️ Avertissement légal : l'utilisation de cette charge sur une infrastructure tierce, sans autorisation écrite, peut entraîner des poursuites judiciaires. Limitez son usage à vos propres projets ou environnements de test contrôlés.

Pour les plus techniques d'entre vous :

Le logiciel cURL est votre allié pour ce genre de stress-tests, si vous n'avez pas accès à une interface en ligne de commande (CLI) sous GNU/Linux, vous pouvez utiliser le site https://reqbin.com/curl.

Voici comment réaliser quelques tests sur les vecteurs de niveau junior à confirmé (GET / POST / JSON / COOKIE / HEADER HTTP) :

1. Transformez la charge utile fournie précédemment en version urlencode, par exemple via la CLI : php -r 'echo urlencode("payload");'

ou en ligne : https://www.urlencoder.org/

Pour la suite des tests, nous supposerons que votre page d'accueil est accessible à l'URL suivante : https://www.test.fr/fr/

2. Vérifiez que l'outil que vous utilisez pour effectuer ces stress-tests a bien accès à votre site.

Certains hébergeurs bloquent par défaut les plateformes comme reqbin, ce qui fausse les résultats.

Si votre hébergeur, infogérance ou développeur refuse que vous effectuiez ces tests, considérez que vous ne disposez d'aucune protection effective. Il est peut-être temps de changer de prestataire.

Aucun professionnel maîtrisant sérieusement la sécurité applicative ne redoute ce type de vérification. Bien au contraire : cela valorise la qualité de ses services - ou met en lumière des fragilités à corriger, ce qui reste une opportunité de progression.

3. Créez la ligne de commande adaptée, à copier-coller en CLI ou dans reqbin.com/curl :

🔹 Vecteur GET :
curl -v 'https://www.test.fr/fr/?id_708842=payload_urlencodé'

🔹 Vecteur POST :
curl -v 'https://www.test.fr/fr/' -d 'id_464770=payload_urlencodé'

🔹 Vecteur JSON :
curl -v 'https://www.test.fr/fr/' -H 'content-type:application/json' -d '{"id_807849":"payload_urlencodé"}'

🔹 Vecteur COOKIE :
curl -v 'https://www.test.fr/fr/' --cookie 'id_998752=payload_urlencodé'

🔹 Vecteur HEADER HTTP :
curl -v 'https://www.test.fr/fr/' -H 'id_261762: payload_urlencodé'

4. Constatez que ces liens sont bloqués par des erreurs de type 403, 405 ou 406. Tout autre retour doit être interprété comme un échec de filtrage : vous êtes donc exposé à ce type de piratage, même par des attaquants de niveau junior.

🛡️ Notre diagnostiqueur de WAF PrestaShop est conçu pour vous aider efficacement :

Il simule plus de 5 000 patterns d'attaque sur l'ensemble des vecteurs d'appels, classés du niveau junior à senior, et les pondère selon leur criticité afin de vous permettre de prioriser intelligemment la mise en place de vos règles de sécurité.

💡 Solutions pour la menace 3 : fuites de données des constructeurs de thèmes (theme builder)

Les éditeurs visuels intégrés aux backoffices (aussi appelés "theme builders") facilitent la mise en page mais rendent également possible l'exposition de données sensibles dans des blocs de contenu publics - à l'insu même de l'administrateur.

Cette menace est silencieuse, durable, et difficile à détecter. Elle nécessite donc des méthodes adaptées, selon le niveau de maturité de votre écosystème technique :

🔹 Variante simple : une routine de surveillance doit être mise en place pour scanner régulièrement la base de données, en particulier les champs à forte exposition via ces éditeurs : descriptif produit et page CMS en priorité, etc.
🔸 Variante avancée : les journaux de consultation du site (journaux d'accès d'Apache2/Nginx) doivent être analysés en temps réel. Si une adresse IP inconnue accède à une URL contenant un secret (lien de backoffice / token sensible), une alerte doit être immédiatement levée pour audit.
🔺 Variante experte : si vous utilisez ModSecurity2, la phase 5 (logging) peut être exploitée pour détecter dynamiquement les exfiltrations de secrets dans la réponse HTML transmise au navigateur. Chaque page générée côté PrestaShop peut être analysée à la volée, et un journal enrichi peut être produit en cas de fuite détectée. Si une adresse IP inconnue consulte une page dont le contenu HTML contient un secret, une alerte est levée pour audit.

Quel que soit le niveau choisi, le mot d'ordre est simple : la confiance n'exclut pas le contrôle. Ce qui a été glissé-déposé accidentellement dans une page par un administrateur aujourd'hui peut ouvrir une faille demain.

Pour les plus techniques d'entre vous : configurer votre SIEM (Security Information and Event Management) afin de surveiller les appels vers des liens contenant des secrets (lien de BO, token, etc) vous permettra de détecter proactivement des fuites potentielles.

Avec l'essor des usages de LLM comme ChatGPT dans les contextes professionnels, nous anticipons une vague de fuites par copiés/collés non maîtrisés - notamment de la part de collaborateurs ou prestataires. Une écoute ciblée sur ces patterns dans vos journaux permettra non seulement de limiter les dommages mais aussi de sensibiliser les marchands utilisant PrestaShop ainsi que vos équipes à ces comportements à risque.

💡 Solutions pour la menace 4 : Détournement de clés d'API via un vol ou une injection

Les clés d'API, bien que pratiques pour automatiser certaines opérations, représentent une surface d'attaque critique dès lors qu'elles sont mal gérées ou exploitées en dehors d'un cadre strictement contrôlé.

Dans une majorité de cas d'exploitation réelle, la compromission passe totalement inaperçue : l'attaquant n'a pas besoin de casser quoi que ce soit - il lui suffit d'utiliser la clé, comme prévu, mais depuis un contexte inattendu.

Pour limiter efficacement ce type d'abus, tous les appels à l'API doivent impérativement être surveillés, journalisés, et analysés. En particulier, il convient de déclencher une alerte immédiate si une adresse IP non autorisée effectue un appel authentifié via une clé API.

Cela implique de maintenir une liste d'adresses IP de services tiers connus, et de considérer tout appel sortant de ce périmètre comme suspect par défaut.

En l'absence de ce niveau de traçabilité et d'alerte, il est parfaitement possible qu'un attaquant exploite une clé valide pendant plusieurs semaines ou mois, sans jamais être détecté.

Pendant ce temps, il peut exfiltrer des données sensibles (incluant des clés vers des API bancaires) ou injecter des données à la volée (incluant des configurations relatives à la sécurité).

Pour les plus techniques d'entre vous : les cas d'usage légitimes nécessitant un accès global au endpoint /api/configurations sont extrêmement rares. Nous vous recommandons donc de paralyser complètement ce point d'entrée (non outrepassable par liste blanche) et d'autoriser les accès, au cas par cas, à des configurations bien précises. Par exemple : /api/configurations/?filter[name]=[PS_COUNTRY_DEFAULT|PS_LOCALE_COUNTRY|PS_LOCALE_LANGUAGE|PS_TIMEZONE]

🧩 Sécuriser, c'est résister à la désécurisation non maîtrisée

Comme vous l'avez déjà compris - ou le comprendrez rapidement en suivant nos prérogatives - la véritable difficulté en sécurité n'est pas de sécuriser PrestaShop, mais de maintenir durablement ces protections.

Mettre en place un WAF professionnel, ajouter des règles de sécurité, restreindre l'accès IP : tout cela peut être réalisé en quelques lignes de commande. En moins d'une heure, un site peut être sécurisé à un niveau jugé satisfaisant... du moins sur le papier.

Car très vite, ces protections vont bloquer des flux "légitimes" : le retour de paiement ne passe plus, le logisticien est verrouillé, l'ERP n'accède plus aux API, ou un développeur tiers perd l'accès au BO. Et dans la panique, on retire la règle. On débloque un user-agent en urgence. On désactive une protection "juste pour tester"... et on oublie de la remettre.

C'est ici qu'un SIEM (Security Information and Event Management) devient indispensable : il permet de superviser de manière centralisée tous les blocages de sécurité et d'identifier rapidement - avec précision - quels acteurs ou services sont concernés. Ce suivi permet de débloquer proprement ce qui doit l'être, sans compromettre l'ensemble du système. Il s'agit d'un filet de sécurité opérationnel, essentiel dans tout environnement E-Commerce.

C'est cela, la désécurisation sécuritaire : non pas une faiblesse ou une erreur, mais une adaptation contrôlée et maîtrisée de vos protections, rendue nécessaire pour maintenir l'équilibre entre sécurité et continuité de service. L'objectif n'est pas de supprimer les règles de sécurité, mais d'assumer que certains blocages vont nécessairement survenir, et qu'il faut les lever avec méthode, sans remettre en cause tout le socle défensif.

Lutter contre les attaques, c'est une chose. Mais lutter contre la désécurisation non maîtrisée, c'est un effort permanent.

Ce ne sont pas les criminels qui affaiblissent vos défenses : ce sont vos exigences.

et/ou celles de vos prestataires, les urgences internes et les intégrations nouvelles... si elles ne sont pas accompagnées sérieusement.

Lorsque vos prestataires refusent de déployer un WAF de niveau professionnel, ne partez pas du principe qu'ils sont incompétents. C'est toujours une question d'argent.

À moins de 500 € HT/mois (hors hébergement), il est tout à fait normal qu'aucune prestation sérieuse n'intègre :

la maintenance quotidienne d'un jeu de règles de sécurité de niveau professionnel stressé par des sociétés spécialisées comme Qualys,
l'enrichissement journalier d'un SIEM adapté à votre contexte métier pour permettre un suivi pro-actif des blocages / fuites – qu'ils soient légitimes ou non.
et la capacité d'ajuster, sous astreinte, les règles de sécurité lors de conflits techniques ou d'intégration de nouveaux outils avec une expertise senior DevSecOps.

La sécurité professionnelle ne peut pas être "désactivée" en un clic.

Elle implique un suivi actif, une veille constante, et une capacité à arbitrer en temps réel entre protection et continuité de service.

En résumé : si vos dépenses en service (hors hébergement) sont inférieures à 500 € HT/mois et que votre boutique génère plus d'un million d'euros de chiffre d'affaires par an, il est quasi certain que des négligences existeront - qu'il s'agisse d'un SIEM inexistant ou passif, ou de règles de sécurité trop laxistes.

Le problème n'est pas le prestataire, mais l'enveloppe que vous lui donnez, qui n'est plus adaptée aux menaces modernes.

💡 Le métier de DevSecOps : sécuriser sans bloquer, protéger sans casser

Pour les plus techniques d'entre vous - qui savent ce qu'est un WAF professionnel - le métier de DevSecOps consiste précisément à éviter ce genre de raccourci : SecRuleRemoveByTag platform-multi.

Ce que beaucoup appliquent "temporairement" finit par désactiver 95 % des protections, globalement, sans retour arrière.

L'une des prérogatives des DevSecOps - infogérance spécialisée dans la sécurisation PrestaShop professionnelle - est d'écrire des règles comme celle-ci :

SecRule REMOTE_ADDR "@ipMatch {file-friendly_range-logistic_c****},{file-friendly_range-logistic_s****}" "id:1,phase:1,pass,nolog,chain"
SecRule REQUEST_URI "@rx ^/api/[\w]+" "chain"
SecRule REQUEST_HEADERS:Content-Type "!@rx ^(application/(soap\+)?|text/)xml" "ctl:ruleRemoveById=98920002,ctl:requestBodyProcessor=XML"

Dans cet exemple, ces deux logisticiens (d'envergure internationale et anonymisés pour éviter des frictions inutiles) envoient un Content-Type non conforme, ce qui est strictement interdit car cela a pour effet de désactiver l'interpréteur XML.

Par conséquent, toutes les règles de sécurité qui opèrent une analyse fine de la valeur des arguments XML (et pas simplement leur nom) deviennent inopérantes.

Notre métier consiste à

Autoriser de manière encadrée ce comportement inadapté pour ne pas bloquer ces logisticiens sur leurs adresses IP identifiées par nos automates
Réactiver l'interpréteur XML manuellement, afin de garantir que les valeurs portées par les arguments XML sont correctement analysées, conformément aux exigences de sécurité

Un SIEM professionnel permet aux infogérances maîtrisant la sécurité applicative de détecter ces blocages en quelques dizaines de secondes avant que l'expertise DevSecOps ne prenne le relais pour produire les règles personnalisées appropriées.

Cela permet, in fine, de détecter et de corriger ce qui doit l'être en moins de 3 minutes en moyenne, sans jamais compromettre la sécurité globale du projet.

Si la mise en oeuvre des solutions vous semble compliquée, nous vous encourageons à contacter une infogérance PrestaShop spécialisée en sécurité professionnelle - pour qui la détection, l'alerte et la remédiation sont un métier, pas un hasard.

Comment sécuriser PrestaShop ?