FAQ

Les headers CSP (Content Security Policy) sont une mesure de sécurité utilisée dans le développement web pour prévenir certaines attaques, notamment les attaques de type Cross-Site Scripting (XSS) et les injections de données. 

En pratique, PrestaFence envoie une directive au navigateur de vos visiteurs qui déclare la liste des domaines de confiance quand vous avez besoin de charger un contenu sur une ressource externe tel qu’un JavaScript, un feuille de style, une image, une iframe… elle permet aussi de d’exiger la vérification de  l’intégrité des scripts chargés localement.

Oui. PrestaFence gère les headers CSP. Il existe 3 modes quand on active cette option :

• report only : cette configuration permet d’activer sereinement. Les violations de CSP sont alors reportées dans votre backoffice. Un assistant permet de créer les règles.
• En forced : les règles sont appliquées 
• Enforced with report : les règles sont appliquées et les violations sont reportées en backoffice.

Oui. PrestaFence prévoit des règles selon le backoffice, la page Checkout et les autres pages du front office.

La définition des headers CSP a pour but de bloquer tout élément chargé qui n’est pas signalé comme étant de confiance. A ce titre, il est important d’observer une période dite « report only » pour lister l’ensemble des violations en les complétant en plusieurs itérations.

A noter que les scripts de reciblage publicitaire et globalement les scripts portés par votre tag manager restent difficilement contrôlable…

Les headers CSP protègent contre les chargements « illégaux ». Donc le chargement en front office d’une iframe frauduleuse chargeant un formulaire usurpé de carte bancaire sur une autre domaine que le vôtre sera bloqué.

En revanche, si vous autorisez le chargement d’une iframe sur un domaine réputé de confiance qui elle-même ne prévoit pas de CSP et est vulnérable à une XSS, cette dernière s’affichera avec tout ce qu’elle a de hacké. Cela dit, les conditions d’exploitation restent beaucoup plus difficiles car l’échange entre la fenêtre enfant vers parent 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.

Pour faciliter la rédaction des règles CSP, PrestaFence interprète les violations et les transforme en règle qui va ajouter à votre header.

Pour demander à PrestaFence de générer les règles à partir des violations, veuillez cliquer sur l’icône tube à essai située au-dessus de la liste des violations. Confirmer ensuite la génération des règles. Il est important de procéder par itération car un blocage de script peut en bloquer un autre. Entre chaque itération vous pouvez purger la table des violations de CSP, visitez à nouveau votre site et recommencer jusqu’à épuisement des reports.

Oui c’est parfaitement possible. Si une règle est définie via un hook, cette dernière ne sera pas suppressible depuis le backoffice et s'ajoute automatiquement dans le header CSP.

Il existe 3 hooks : 

• actionDeclareBackofficeCspHeader pour le back office
• actionDeclareCheckoutCspHeader pour la page checkout du frontoffice
• actionDeclareFrontofficeCspHeader pour toutes les autres pages du frontoffice

Voici un exemple :

Oui PrestaFence les CSP des modules développés par 202 ecommerce sont pris en charges :

• Axeptio
• Braintree Official
• Delivengo
• FloaPay
• Paypal Official
• Stripe Official
• Trustedshops fast integration 
• Younited Credit 

En outre, les services qui publient officiellement dans leur documentation publique sa politique CSP peuvent être ajoutés comme :

• ReCaptcha

D’abord, nos conseils sont les suivants :

N'embarquez aucun service tiers qui n’est pas absolument nécessaire. Par exemple, une carte tel que Openstreet map nécessite effectivement des CSP, mais des fonts sur un ou plusieurs CDN devraient être intégrés au sein du module.

Certains marchands ont la nécessité de définir des CSP strictes, c’est à dire sans directives unsafe-eval ni unsafe-eval. N’utilisez pas les eval JavaScript ni le code css, JavaScript, … au sein du html.

Une fois ces conseils appliqués, reportez-vous à la FAQ : Comment déclarer mes règles CSP via un hook ?

Un WAF est un firewall applicatif. Il a pour but de stopper les robots malveillants qui souhaitent exploiter des vulnérabilités. Des expressions régulières sont utilisées pour bloquer les pirates avant qu’ils n’atteignent le cœur de votre boutique PrestaShop.

Non. PrestaFence est une solution d’atténuation des risques et ne peut, de par sa conception, être exhaustif. Nous travaillons constamment le taux de blocage à mettre en rapport avec le taux de faux positif (blocage non désiré). C’est pourquoi il est important de rester à jour des règles que propose PrestaFence.

PrestaFence est un module grand public, accessible à tous les marchands et n’a pas nécessairement vocation à avoir le meilleur taux de blocage du marché mais de couvrir les menaces les plus courantes. Pour atteindre un niveau de blocage attendu pour certains services critiques, il est nécessaire de contractualiser avec une infogérance professionnelle qui dispose d’une astreinte pour évaluer la menace en permanence et ajuster les blocages non désirés. Voir notre offre dédiée.

Avec PrestaFence, vous êtes le seul maître à bord ! Vous avez la possibilité de suspendre toute règle qui vous incommode, mais aussi de restreindre ou whitelister un chemin pour tout le monde ou sur IP…

PrestaFence WAF bloque notamment :

• Les vulnérabilités CVE dans les modules dont le travail repose essentiellement sur la recherche des sociétés TouchWeb et 202 ecommerce.
• Les patterns triviales de SQLi (Sql injection)
• Les patterns triviales de RCE (Remote Code Exécution)
• Les patterns triviales de XSS
• Certaines formes de SSRF
• Les fuites de données
• Les XXE

En revanche, les faiblesses logiques (IDOR) ne peuvent pas être traitées par essence.

Non. Le module PrestaFence est complètement autonome. Seules les mises à jour permettent d’obtenir les nouvelles règles du WAF qui s’adaptent à la menace.

Pour les marchands les plus soucieux de la sécurité de leur site et de traiter plus finement les blocages indésirables, nous proposons un service de firewall incluant l’infogérance : voir notre offre PrestaFence Cloud.

Non, vos données restent vos données et ne sont pas transmises vers des serveurs de traitement chez PrestaFence. Cependant, afin d’évaluer la pertinence de certaines règles, des statistiques quantitatives de blocage peuvent être partagées avec PrestaFence.

Oui. Chaque règle est unitairement désactivable. Il existe plus d’une centaine de règles spécifiques ou génériques en fonction de vos besoins pour limiter les risques de faux positifs.

Pour savoir comment démarrer suivez notre guide d’activation.

Non, pour le moment cette fonctionnalité n’existe pas.

Le mode « Apprentissage » (report only) permet de jouer toutes les règles du WAF mais les blocages et captcha ne seront pas exécutés. Ainsi tous les événements seront historisés permettant de déterminer si des faux positifs (blocage de trafic légitime) sont présents. Si c’est le cas, vous reporter à « Comment démarrer l’activation du WAF PrestaFence ».

Remarque : pour plus d’efficacité de filtrage, certaines règles font appel à des RewriteRule déposés dans le htaccess. Afin de ne pas bloquer les requêtes, ces dernières ne sont pas déployées ce qui constitue une différence significative de traitement des fuites de données.

Non. Les règles du WAF forment un tout et ne peuvent être dissociées.

La méthode recommandée est de désactiver les règles en cas de doute puis de les réactiver une à une en laissant passer un certain délai entre chaque. L’analyse des événements permettra de vous assurer qu’il n’y a pas de faux positifs.

Nous recommandons l’activation du mode « Report only » durant une période significative. Selon votre trafic cela peut varier de quelques jours à 1 mois le temps d’identifier dans la liste des événements ceux qui nécessitent des ajustements.

Les ajustements peuvent être de plusieurs ordres :

• Le whitelistage par IP et/ou chemin
• La correction d’un bug ou le déplacement d’un script dans un chemin plus sécurisé
• La désactivation d’une règle 

Attention : l’une ou l’autre des 3 solutions proposées ci-dessus ouvre de fait une brèche et abaisse le niveau de protection. Il est donc important de limiter au maximum la surface d’exposition.

Un faux positif est une règle de blocage déclenchée alors que le trafic est légitime.

Le meilleur moyen de suivre les blocages est de s’abonner aux notifications. Pour cela, comment activer les notifications du WAF PrestaFence.

Pour activer les notifications, se rendre dans votre back-office à la rubrique :

protéger mon backoffice

Notifications

Pour pouvez choisir de recevoir des notifications instantanées pour chaque événement déclenchant une mise à jour de l’IP manager et éventuellement un résumé quotidien voire hebdomadaire.

Une règle de priorité 20 (voir la FAQ sur les règles du waf), activée par défaut, bypass toutes les règles du WAF. Nous recommandons de laisser cette règle activée.

Si vous préférez activer le waf sur le backoffice, pensez à créer une règle du manager d’IP pour (voir FAQ dédiée) whitelister votre IP avec une priorité inférieure (5 par exemple).

Si le firewall continue à vous bloquer, purger votre IP dans votre base de données dans la table prestafence_ip pour recouvrir votre accès au backoffice.

Certaines règles déclenchent un blocage direct car la menace est considérée comme réelle et sérieuse et automatisée par un robot. D’autres règles présentant potentiellement plus de faux positifs peuvent déclencher un captcha qu’un humain peut valider.

NB : une fois le captcha validé, il est nécessaire de valider ce dernier pour ouvrir n’importe quelle autre page du site.

Comment fonctionne le blocage du WAF PrestaFence ?

Si une requête portant une charge malveillante est détectée, elle sera immédiatement bloquée avant de rentrer dans 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 sera bloquée pour l’ensemble des requêtes suivantes pour une durée de plusieurs jours.

Oui. Le démarrage (bootstrap) du WAF se fait au niveau du chargement des configurations de PrestaShop par défaut mais le htaccess prend le relais pour charger le WAF. Si le fichier appelé est une css, un js ou autre alors le WAF ne se déclenche pas. Mais dans ce cas, des règles de réécriture peuvent s’appliquer.

Non. En revanche, disposer d’un WAF peut altérer l’efficacité de PrestaFence. Mieux vaut un seul WAF finement configuré que deux moyennement configurés…

Comment fonctionnent les priorités du manager d’IP ?

Chaque règle du WAF ainsi que chaque ligne de l’IP manager dispose d’une priorité. Plus celle-ci est faible, plus elle sera évaluée tôt par le WAF. Ensuite, si une règle « match » avec la requête entrante, l’action qui lui est assignée est déclenchée. Les règles suivantes ne seront pas exécutées.

Ainsi pour whitelister une IP ou/et une URI, il faut créer une règle SKIP avec une priorité plus faible qu’une règle de blocage. Et inversement.

Pour ses règles, PrestaFence utilise les plages de priorité suivantes :

• 0 à 9 : non utilisé par PrestaFence
• 10 : Double Authentification 
• 10 à 49 : whitelist générique type backoffice, recaptacha
• 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ée 
• 300 à 399 : règles de blocage générique 
• 400 à 499 : non utilisée
• 500 et plus : règle déclenchant un log uniquement. Peut être utilisée pour tester une règle de blocage.

Une règle de type whitelist est une règle du WAF qui permet de bypasser toute les règles qui ont une priorité plus forte. L’action associée est appelée “SKIP”.

Une règle de type blacklist est une règle du WAF qui permet de retourner une action de blocage (BLOCK).

La greylist est une liste d’IP qui suit les règles de blocage ou non blocage prévue par PrestaFence mais qui ne pourra pas être blacklistée quel que soit le nombre d'échecs. Cela peut être utile lors d’un pentest d’ajouter les IP des serveurs d’attaque afin d’évaluer vos défenses sans tenir compte de la blacklist. Enfin les IP des principaux moteurs de recherche Google et Bing sont greylistés de sorte que le crawling d’une vulnérabilité ne bloque pas le robot.

Le WAF PrestaFence dispose de deux règles, une pour GoogleBot, l’autre pour MsnBot permettant de greylister les IP de ces moteurs de recherche. Ainsi, s’ils crawl une URL contenant une vulnérabilité, ils ne seront jamais permaban.

TOR est un projet de proxy anonyme qui permet à tout internaute de ne pas être tracé. Si la vocation initiale qui est d’éviter le pistage est détourné par des hackers malintentionnés pour passer des attaques malveillantes ou explorer des vulnérabilités de votre site sans permettre d’être retrouvé. Aussi les exit nodes TOR font l’objet d’une règle du WAF activé par défaut mais qui peut être désactivé à tout moment.

Il existe des règles spécifiques pour les modules StripeOfficial et Paypal Officiel afin de whitelister les IP sur le chemin des webhooks respectifs. Cela permet de renforcer la sécurité en assurant de ne pas avoir d’erreur.

Nous pouvons ajouter d’autres solutions mais ces dernières doivent déclarer leur IP publiquement

Vous pouvez utiliser l’IP manager pour créer des règles mais avant cela il est nécessaire de désactiver la règle de whitelist du backoffice. 

Attention pour éviter tout blocage de votre backoffice, veillez à respecter l’ordre des étapes !

Se rendre dans les configurations générales 

Désactiver la règle de priorité 5 portant la référence WHITELIST-BO

Se rendre dans l’IP manager

Créer une première règle Whitelist en indiquant 

…

Le manager IP de PrestaFence permet de créer des règles du WAF par IP, par chemin ou un mix des deux.

Un déblocage, c'est-à-dire faire en sorte que le WAF n’applique aucune règle sur un chemin revient à appliquer une action Whitelist sur un chemin.

Pour cela :

• Se rendre dans l’IP manager dans le backoffice du module PrestaFence
• Créer une nouvelle règle de WAF.
• Saisir comme chemin votre chemin (raw URI) par exemple /module/mymodule/mycontroller. Cette syntaxe est automatiquement interprétée par PrestaFence comme une URL de module front controller

Mon site est peut-être infecté, PrestaFence peut-il m’aider ?

PrestaFence est actuellement centré sur la prévention et l’atténuation des risques et s’installe sur un PrestaShop sein.

PrestaFence ne permet pas l’analyse de code pour détecter des malwares de type backdoor ou autre. Le Firewall applicatif ne saura pas stopper une menace de ce type.

Un de vos visiteurs tombe systématiquement sur la page d’accès interdit quelque soit la page qu’il visite et vous souhaitez le sortir de la blacklist pour qu’il recouvre l’accès à votre site PrestaShop. Veuillez suivre les étapes suivantes :

• Demandez à votre visiteur son IP ou l’identifiant de requêtes présent sur la page d’accès interdit en bas de page. A défaut une heure approximative de la visite.
• A partir de l’une de ces informations, rechercher dans liste des événements celui correspondant à votre visiteur et notez l’IP de ce dernier.
• Rendez vous dans le tableau de l'IP manager, rechercher et supprimer toutes les lignes correspondant à cette IP.

Apache ou NGinx, y a-t-il une différence pour PrestaFence ?

PrestaFence crée des règles dans le fichier .htaccess pour bloquer les accès aux fichiers directs ou certaines IP malveillantes. Ainsi PrestaFence sera plus efficace sur Apache si votre Nginx ne dispose pas de plugins pour interpréter le fichier .htaccess.

Habituellement, on configure ceci : 

error_page 404 /index.php?controller=404;

Nous proposons de modifier la configuration Nginx comme suit : 

error_page 404 = @handle_errors;

location @handle_errors {

    include fastcgi_params;

    fastcgi_param SCRIPT_FILENAME $document_root/index.php;

    fastcgi_param QUERY_STRING controller=404;

    fastcgi_pass unix:/var/run/php/8.1-fpm.sock;

}

location ~ [^/]\.php(/|$) {

    # on charge boostrap.php s’il existe, sinon $uri

    try_files /modules/prestafence/bootstrap.php $uri =404;

    fastcgi_pass unix:/var/run/php/8.1$php_version-fpm.sock;

    if (!-f $document_root$fastcgi_script_name) {

        return 404;

    }

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    # Définir REDIRECT_URL pour PrestaFence

    fastcgi_param REDIRECT_URL $request_uri;

    include fastcgi_params;

}

Certaines personnes bookmarkent sur leur navigateur un raccourci. Pour éviter de les bannir en cas de tentative trop nombreuse sur un ancien chemin de BO, il est recommandé de créer une règle de type Greylist : 

• Rule: GREYLIST
• URI: /admin_mon_ancien_chemin
• IP: laisser vide
• Title: Greylist ancien chemin du BO
• Priority: 1000
• Management: MANUAL

De cette manière, le chemin apparaîtra avec la page d’interdiction mais les visiteurs ne seront pas bannis.

Votre utilisation de PrestaFence met en évidence que de nombreux robots essayent de trouver et deviner la présence de scripts PHP. Vous souhaitez légitimement bloquer les scripts et ne laisser passer que quelques un légitime. Nous proposons ici un protocole en 3 étapes :

Créer une règle de pour observer les appels sur des scripts PHP en direct

Vous pouvez créer une règle dans l’IP manager

• Rule: LOG
• URI: ^(?!.*index\.php$).*\.php$
• IP: laisser vide
• Title: Scripts PHP standalone
• Priority: 1500
• Management: MANUAL
• Active: True

Attention : respectez bien les priorités !

Cette règle va permettre d'ajouter un événement de tous les appels PHP légitimes ou non. Au fur et à mesure que des faux positifs sont détectés, vous pouvez passer à l’étape 2.

Créer une règle pour whitelister les 

• Rule: WHITELIST
• URI: ^/(modules/yyy/validation|modules/xxx/).*\.php$
• IP: laisser vide sauf si vous souhaitez réserver l’accès sur IP
• Title: Whitelist de Scripts PHP standalone
• Priority: 135
• Management: MANUAL
• Active: True

Attention : respectez bien les priorités !

Passé quelques jours, vous pourrez remplacer la règle de 1 de LOG par 

• Rule: BLOCK
• URI: ^(?!.*index\.php$).*\.php$
• IP: laisser vide
• Title: Blocage de scripts PHP standalone
• Priority: 136
• Management: MANUAL
• Active: True

Attention : respectez bien les priorités !

Module Colissimo

• Rule: WHITELIST
• IP: laisser vide (tous les visiteurs)
• URI: /modules/colissimo/DataTables_fr.json
• Title: Json module colissimo
• Priority: 90
• Management: MANUAL
• Active: True

Module StoreCommander

• Rule: WHITELIST
• IP: laisser vide (tous les visiteurs)
• URI: /modules/storecommander/(.+)
• Title: Store Commander
• Priority: 90
• Management: MANUAL
• Active: True

Module Shopping cart (tel que ls_shopppingcart)

Cette règle permet de prévenir les conflits entre la règle 015 (SQLi) et le paramètre delete-from-cart qui lève une blocage : 

• Rule: EXEMPT
• IP: laisser vide (tous les visiteurs)
• URI: /module/ls_shopppingcart/ajax 
• Title: Exempt prestafence-015 Report
• Priority: 300
• Management: MANUAL
• Active: True
• Exempt list : prestafence-015

Oui. Notre solution est actuellement basée sur l’envoi d’un e-mail à l’administrateur qui doit saisir le code reçu. Nous étudions actuellement l’ajout du protocole TOTP compatible Google Authenticator.

La double authentification aussi appelée authentification à deux facteurs permet d’introduire un élément physique en possession du détenteur d’un compte lors de l’authentification. Par exemple, un SMS, une application sur mobile sont considérées comme des authentifications fortes et garantissent que le vol d’un identifiant et de son mot de passe ne permet pas à lui seul d’accéder à un compte administrateur.

Non. Nous souhaitons que notre solution soit fiable et robuste et réponde aux exigences de la PCI DSS (en SAQ-A). Aussi PrestaFence ne permettra pas de by-passer cette règle essentielle de sécurité : chaque administrateur doit disposer d’un compte nominatif dont les droits sont juste proportionnés ce qui suppose une adresse e-mail valide et accessible par son seul détenteur.

Si cette contrainte est trop forte pour votre usage, vous pouvez désactiver la double authentification temporairement. Dans ce cas, nous recommandons l’ajout d’une restriction au backoffice par IP. Voir comment configurer une restriction IP (Todo).

Non. Mais c’est prévu !

Nous avons opté prioritairement pour une solution simple et facilement adoptable par tous les administrateurs. En effet, les modules qui ne proposent que la double authentification TOTP oblige un administrateur à configurer les QRcode des autres administrateurs rendant complexe la mise en place à tous les employés. La conséquence est qu’une minorité d’administrateurs sont configurés rendant caduque l’intérêt d’une double authentification.

Le bruteforce est une technique qui permet de deviner un couple identifiant / mot de passe par la soumission en masse d’un formulaire d’authentification. PrestaFence ne dispose pas encore de solution permettant de prévenir ce type d’attaque. C'est en revanche disponible en Frontoffice.

Le credential stuffing est l’utilisation malveillante de base de données d’identifiant / mot de passe valide volés afin de détourner des comptes sur votre site ecommerce. La double authentification protège contre ce type d’attaque.

Vos clients utilisent peut-être le « vaulting » de leur carte bancaire sur votre site ecommerce. Vous disposez peut-être d’un programme de fidélité avantageux. Dans ce cas, des pirates peuvent être intéressés par le détournement de comptes clients pour utiliser leurs moyens de paiement stockés sur votre site. Aussi une double authentification du front office constitue un moyen efficace de protéger vos clients du vol de leur données. Votre formulaire en front office peut aussi être protégé par une double authentification (voir Protéger mon front-office).

Vous souhaitez donner un accès à votre backoffice mais la mise en place d’une double authentification vous est contraignante. Vous disposez d’une IP fixe chez votre fournisseur d’accès internet, dans ce cas, vous pouvez créer un règles Exempt pour cette IP pour l’uri de votre backoffice avec une priorité 300.

Remarque : cette procédure permet de by-passer la règle de double authentification.

Le code est envoyé par PrestaShop, vérifiez :

Que la délivrabilité des e-mails par votre serveur ou votre transitaire n’est pas touché. Pour s’en assurer, vous pouvez tenter une action qui envoie un e-mail comme un rappel de mot de passe.

Que le message n’est pas tombé en SPAM dans votre boîte.

Si vous n’avez pas reçu ce peut être aussi parce qu’aucun administrateur n’existe avec cet e-mail… vérifier qu’une erreur de saisie n’est pas à l’origine de votre problème.

Mon code de double authentification ne fonctionne pas, que faire ?

Oui. La protection contre le bruteforce de l’authentification est activable en FrontOffice.

Oui. Une double authentification est activable en FrontOffice.

Oui. Un tableau des authentifications réussies ou non est disponible en backoffice pour vous permettre de surveiller les activités suspectes telles que les attaques en bruteforce, authentifications en échec ou réussies, ...

Vos clients peuvent avoir été victime de vols de données sensibles comme leurs identifiants et mots de passe.

Aussi : 

• Si vous permettez à vos clients d’enregistrer leur moyen de paiement sur leur espace personnel (CB, …).
• Si vous fournissez un système de prépaiement (portefeuille prépayé) tel que des cartes cadeaux utilisable.
• Si vous proposez des produits dématérialisés, facilement “recelable” tels que des ebooks, des logiciels, …
• Si vous proposez des abonnements accessible en ligne
• …

alors, l'accès au compte personnel de vos clients peut attiser les convoitises car ils renferment une valeur potentielle. Dans ce cas, la mise en place d’une double authentification.

Un code d’authentification est envoyé par email à la personne qui s’authentifie. Ce code est à reporter dans le formulaire suivant la saisie du login / mot de passe.

Non. Le module PrestaFence ne permet pas nativement de gérer la désactivation de la double authentification par un client.Cependant, le hook actionPrestafenceFrontOtp permet à un développeur d'ajouter cette fonctionnalité.

Non. Le module PrestaFence ne permet pas nativement de gérer la désactivation de la double authentification par client.Cependant, le hook actionPrestafenceFrontOtp permet à un développeur d'ajouter cette fonctionnalité.

Non. Le module PrestaFence ne permet pas nativement de gérer de code envoyé par SMS ou d’utiliser le protocole TOTP géré par Google Authenticator ou équivalent.Cependant, le hook actionPrestafenceFrontOtp permet à un développeur d'ajouter cette fonctionnalité.

Cette fonctionnalité incluant une modification de l’authentification, il est possible que le formulaire de saisie du code ne s’affiche pas correctement selon le thème utilisé.

Veuillez tester impérativement la fonctionnalité avant de la mettre en production.

Le formulaire respecte le thème “Classic” de PrestaShop et s’insère de manière transparente sur le template _partials/login-form.tpl (voir méthode TOTPPrefilter::addFrontOfficeTOTPField). Si votre thème ne change pas le formulaire de login dans ce template, overrider ou remplacer les éléments présents du template suivant : modules/prestafence/views/templates/front/login-form-totp.tpl

Malheureusement, pas toujours. C’est pourquoi, nous recommandons de coupler PrestaFence Bruteforce et OTP à la mise en place d’une protection tel que CloudFlare Turnstile, ou équivalent, à appliquer sur vos pages d’inscription et de login.

@todo

Hook actionPrestafenceFrontBruteforce ?