Oui. PrestaFence crée des règles dans le .htaccess pour bloquer l’accès direct à certains fichiers ou certaines IP malveillantes. PrestaFence sera donc plus efficace « clés en main » sur Apache. Sur Nginx — qui n’interprète pas le .htaccess — une configuration équivalente doit être ajoutée manuellement (voir les FAQ Nginx ci-dessous).
Chaque règle du WAF, comme chaque ligne de l’IP manager, dispose d’une priorité. Plus elle est faible, plus elle est évaluée tôt. Si une règle « matche » la requête entrante, l’action associée est déclenchée et les règles suivantes ne sont pas exécutées. Ainsi, pour whitelister une IP et/ou une URI, créez une règle SKIP avec une priorité plus faible qu’une règle de blocage (et inversement). Plages de priorité utilisées par PrestaFence :
- 0 à 9 : non utilisé par PrestaFence
- 10 : double authentification
- 10 à 49 : whitelist générique (back-office, reCAPTCHA)
- 50 à 99 : non utilisé par PrestaFence
- 100 à 110 : blocage des CVE
- 120 à 130 : blocage générique, dont 125 : user-agent (peut présenter des faux positifs)
- 140 : probation ou probation captcha
- 150 : soft ban par IP
- 200 à 299 : non utilisé
- 300 à 399 : règles de blocage générique
- 400 à 499 : non utilisé
- 500 et plus : règle déclenchant un log uniquement (utile pour tester une règle de blocage)
Si une requête portant une charge malveillante est détectée, elle est immédiatement bloquée avant d’atteindre le cœur de PrestaShop.
Si une même IP est bloquée plusieurs fois (5 par défaut), elle est mise en liste noire et bloquée sur l’ensemble des requêtes suivantes pour une durée de plusieurs jours.
PrestaShop module, Administrative Mandate (totadministrativemandate) edited by 202 ecommerce <= 1.8.1 is vulnerable to Cross Site Request Forgery (CSRF).
The payment validation controller has no CSRF token. An attacker can create an order in an awaiting status by hijacking a link.
Summary
Published at: 2026-07-29
Advisory source: 202-ecommerce.com
Platform: PrestaShop
Product: totadministrativemandate
Impacted release: <= 1.8.1 (1.8.2 patch)
Product author: 202-ecommerce.com
Weakness: CWE-352 (CSRF)
Severity: medium (5.3)
Possible malicious usage
Due to a leak of verification in the core of PrestaShop, an attacker can create an order in a country where the Administrative Mandate method is not available.
CVSS base metrics
Attack Vector (AV): Network
Attack Complexity (AC): Low
Privileges Required (PR): None
User Interaction (UI): None
Scope (S): Unchanged
Confidentiality (C): None
Integrity (I): Low
Availability (A): None
Timeline
- 2026-04-09: 202-ecommerce discover the vulnerability durring an internal audit
- 2026-04-09: 202-ecommerce request a CVE ID from Mitre
- 2026-05-15: 202-ecommerce publish the fix release 1.8.2 on PrestaShop Marketplace
- 2026-07-20: Mittre assign a CVE ID
- 2026-07-29: Pubication of the CVE
Links
Nos conseils :
Certains marchands ont besoin de définir des CSP strictes, c’est-à-dire sans directives unsafe-inline ni unsafe-eval. N’utilisez donc pas de eval JavaScript ni de code CSS/JavaScript inline dans le HTML.
N’embarquez aucun service tiers qui n’est pas absolument nécessaire. Par exemple, une carte type OpenStreetMap nécessite effectivement des CSP, mais des polices hébergées sur un ou plusieurs CDN devraient plutôt être intégrées au module lui-même.
Une fois ces conseils appliqués, reportez-vous à la FAQ « Comment déclarer mes règles CSP via un hook ? ».
Oui. Les CSP des modules développés par 202 ecommerce sont pris en charge :
- Alma
- Axeptio cookies
- Brevo formerly sendinblue
- Chronopost
- Colissimo
- Crisp
- Doofinder
- DPD france
- Hipay Enterprise
- Mollie
- Mondialrelay
- Paypal Officiel
- Payplug
- ps_checkout
- Trustpilot
- Sendcloudv2
- Shopimind
- Smartsupp
- Stripe Officiel
- Worldlineop
En outre, les services qui publient officiellement leur politique CSP dans leur documentation publique peuvent être ajoutés (ex. : reCAPTCHA).
C’est parfaitement possible. Une règle définie via un hook ne sera pas supprimable depuis le back-office et s’ajoute automatiquement au header CSP.
Trois hooks existent :
actionDeclareFrontofficeCspHeader— pour toutes les autres pages du front-officeactionDeclareBackofficeCspHeader— pour le back-officeactionDeclareCheckoutCspHeader— pour la page checkout du front-office
Voici un exemple :
Pour faciliter la rédaction des règles CSP, PrestaFence interprète les violations et les transforme en règles ajoutées à votre header.
Pour générer les règles à partir des violations, cliquez sur l’icône « tube à essai » située au-dessus de la liste des violations, puis confirmez la génération. Procédez par itération : le blocage d’un script peut en révéler un autre. Entre chaque itération, vous pouvez purger la table des violations CSP, revisiter votre site, et recommencer jusqu’à épuisement des reports.
Les headers CSP bloquent les chargements « illégaux ». Ainsi, le chargement en front-office d’une iframe frauduleuse présentant un faux formulaire de carte bancaire sur un autre domaine que le vôtre sera bloqué.
En revanche, si vous autorisez le chargement d’une iframe depuis un domaine réputé de confiance qui, lui-même, ne prévoit pas de CSP et reste vulnérable à une XSS, celle-ci s’affichera. Cela dit, les conditions d’exploitation restent bien plus difficiles, car l’échange entre la fenêtre enfant et la fenêtre parente est limité.
En résumé, tout comme le WAF, les CSP réduisent l’exposition au risque de manière efficace et indispensable sur un vecteur d’attaque, sans être la solution ultime.
La définition des headers CSP vise à bloquer tout élément chargé qui n’est pas déclaré de confiance. À ce titre, il est important d’observer une période « report only » pour lister l’ensemble des violations et les compléter en plusieurs itérations.
À noter : les scripts de reciblage publicitaire, et plus largement ceux portés par votre tag manager, restent difficilement contrôlables.
Oui. PrestaFence prévoit des règles distinctes pour le back-office, la page Checkout et les autres pages du front-office.
Oui. PrestaFence gère les headers CSP. Trois modes existent lorsque l’on active cette option :
- Enforced with report : les règles sont appliquées et les violations sont reportées en back-office.
- Report only : permet d’activer sereinement. Les violations de CSP sont reportées dans votre back-office. Un assistant aide à créer les règles.
- Enforced : les règles sont appliquées.