FAQ

Un gestionnaire de vulnérabilités est un outil qui permet de vous informer qu’une vulnérabilité a été divulguée publiquement. On parle en général de publication d’une CVE.

Oui. La gestion des vulnérabilités du corps de PrestaShop et des modules est prise en charge par PrestaFence. 

A tout moment vous pouvez consulter la liste des vulnérabilités publiques, vous pouvez masquer la vulnérabilité lorsque vous avez appliqué le patch.

Oui, toutes vulnérabilités publiques est étudiée par nos équipes intégrée à notre base de données et distribuées

Non, mais c’est à l’étude pour les vulnérabilités critiques.

En attendant, nous recommandons de rejoindre les versions LTS de PrestaShop afin de diminuer l’exposition au risque de votre site internet.

PrestaShop : versions 1.7.5+

PHP : version 7.1 ou supérieure

Oui, le changement de serveur implique souvent le changement des accès à la base de données ainsi que d’autres configurations que PrestaFence met en cache pour être efficace. Aussi il est préférable de :

• désactiver le module PrestaFence avant transfert du site sur son nouveau serveur.
• puis le réactiver en arrivant sur le nouveau serveur.

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

En pratique, PrestaFence envoie une directive au navigateur de vos visiteurs : elle déclare la liste des domaines de confiance lorsque vous devez charger une ressource externe (JavaScript, feuille de style, image, iframe…) et permet aussi d'exiger la vérification de l'intégrité des scripts chargés localement.

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.

Oui. PrestaFence prévoit des règles distinctes pour le back-office, la page Checkout et les autres pages du front-office.

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.

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.

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.

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-office
• actionDeclareBackofficeCspHeader — pour le back-office
• actionDeclareCheckoutCspHeader — pour la page checkout du front-office

Voici un exemple :

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).

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 ? ».

PrestaFence est un module PrestaShop conçu pour protéger contre les attaques courantes (SQLi, XSS, Directory Traversal…) visant PrestaShop et ses modules. Si votre installation intègre un autre CMS ou un tiers tel que WordPress, PrestaFence ne couvrira pas cet outil.

PrestaFence est un dispositif utile dans le cadre d'une remédiation, pour redonner au marchand de la visibilité sur les blocages à mettre en place et les affiner, en complément d'un dispositif couvrant d'autres formes d'attaques. À titre d'exemple, un volume systématique de plus de 150 000 événements bloquants sur 30 jours glissants doit lever une alerte, afin d'étudier la pertinence d'une solution complémentaire intégrée à l'hébergement.

PrestaFence ne se veut en aucun cas exhaustif et ne peut couvrir 100 % des attaques (voir FAQ ci-dessous). Il ne dispense pas de réaliser les mises à jour du serveur, de PrestaShop et de ses tiers (modules, thèmes…). Enfin, si votre PrestaShop — ou un autre logiciel partagé sur le même hébergement — contient un ou plusieurs malwares (gestionnaire de fichiers, de base de données, webshell…), PrestaFence ne pourra pas être efficace.

Un WAF est un pare-feu applicatif. Il vise à stopper les robots malveillants qui cherchent à exploiter des vulnérabilités. Des expressions régulières sont utilisées pour bloquer les attaquants 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, par conception, être exhaustif. Nous travaillons constamment le taux de blocage en rapport avec le taux de faux positifs (blocage non désiré). C'est pourquoi il est important de rester à jour des règles proposées par PrestaFence.

PrestaFence est un module grand public, accessible à tous les marchands ; il n'a pas vocation à offrir le meilleur taux de blocage du marché, mais à couvrir les menaces les plus courantes. Pour atteindre un niveau de blocage attendu sur certains services critiques, il est nécessaire de contractualiser avec une infogérance professionnelle disposant 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 restez seul maître à bord : vous pouvez suspendre toute règle qui vous gêne, mais aussi restreindre ou whitelister un chemin pour tout le monde ou par IP.

Le WAF PrestaFence bloque notamment :

• Les vulnérabilités CVE des modules — travail reposant essentiellement sur la recherche des sociétés TouchWeb et 202 ecommerce
• Les patterns triviaux de SQLi (injection SQL)
• Les patterns triviaux de RCE (Remote Code Execution)
• Les patterns triviaux de XSS
• Certaines formes de SSRF
• Les fuites de données
• Les XXE

En revanche, les failles de logique applicative (IDOR) ne peuvent, par nature, être traitées.

Non. Le module PrestaFence est totalement autonome. Seules les mises à jour apportent les nouvelles règles du WAF, adaptées à l'évolution de la menace.

Pour les marchands les plus soucieux de leur sécurité et souhaitant traiter plus finement les blocages indésirables, nous pouvons vous orienter vers un service de firewall avec infogérance : prenez contact avec l'équipe PresatFence.

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 désactivable individuellement. Il existe plus d'une centaine de règles, spécifiques ou génériques, à ajuster selon vos besoins pour limiter les faux positifs. Pour démarrer, suivez notre guide d'activation.

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

Le mode « Apprentissage » (report only) joue toutes les règles du WAF, mais les blocages et captchas ne sont pas exécutés. Tous les événements sont alors historisés, ce qui permet de détecter d'éventuels faux positifs (blocage de trafic légitime). Le cas échéant, reportez-vous à « Comment démarrer l'activation du WAF PrestaFence ».

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

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

La méthode recommandée : désactiver les règles en cas de doute, puis les réactiver une à une en laissant passer un délai entre chacune. L'analyse des événements permet de s'assurer de l'absence de faux positifs.

Nous recommandons d'activer le mode « Report only » durant une période significative. Selon votre trafic, cela peut aller de quelques jours à un mois, le temps d'identifier dans la liste des événements ceux qui nécessitent un ajustement. Les ajustements peuvent être :

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

Attention : chacune de ces solutions 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 (voir « Comment activer les notifications du WAF PrestaFence »).

Rendez-vous dans votre back-office, rubrique Firewall › Notifications. Vous 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 ou hebdomadaire.

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

Si vous préférez activer le WAF sur le back-office, créez une règle de l'IP manager pour whitelister votre IP avec une priorité inférieure (5 par exemple).

Si le firewall continue à vous bloquer, purgez votre IP dans la table prestafence_ip de votre base de données pour recouvrer l'accès.

Certaines règles déclenchent un blocage direct, car la menace est jugée réelle, sérieuse et automatisée par un robot. D'autres règles, présentant davantage de risque de faux positifs, peuvent déclencher un captcha qu'un humain peut valider.

NB : une fois le captcha validé, il reste nécessaire de le valider pour ouvrir toute autre page du site.

Oui. Le démarrage (bootstrap) du WAF s'effectue au 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, le WAF ne se déclenche pas — mais des règles de réécriture peuvent s'appliquer.

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

Une règle de type whitelist permet de bypasser toutes les règles de priorité plus forte. L'action associée s'appelle SKIP.

Une règle de type blacklist retourne une action de blocage (BLOCK).

La greylist est une liste d'IP qui suit les règles de blocage (ou de non-blocage) de PrestaFence, mais qui ne pourra jamais être blacklistée, quel que soit le nombre d'échecs. C'est utile lors d'un pentest, pour ajouter les IP des serveurs d'attaque et évaluer vos défenses sans tenir compte de la blacklist. Enfin, les IP des principaux moteurs de recherche (Google, Bing) sont greylistées, afin que le crawl d'une URL vulnérable ne bloque pas le robot.

Le WAF PrestaFence dispose de deux règles — une pour GoogleBot, une pour MsnBot — qui greylistent les IP de ces moteurs. Ainsi, s'ils crawlent une URL contenant une vulnérabilité, ils ne seront jamais bannis définitivement.

TOR est un projet de proxy anonyme permettant aux internautes de ne pas être tracés. Sa vocation initiale (éviter le pistage) est parfois détournée par des attaquants pour mener des attaques ou explorer des vulnérabilités sans pouvoir être identifiés. Les nœuds de sortie (exit nodes) TOR font donc l'objet d'une règle du WAF activée par défaut, désactivable à tout moment.

Des règles spécifiques existent pour les modules Stripe Official et PayPal Official, afin de whitelister les IP sur le chemin de leurs webhooks respectifs et d'éviter les erreurs. Nous pouvons ajouter d'autres solutions, à condition qu'elles déclarent publiquement leurs IP.

Le gestionnaire de règle permet de créer des règles par IP, par chemin, ou un mix des deux. Whitelister un chemin (pour qu'aucune règle ne s'y applique) revient à appliquer une action Whitelist sur ce chemin :

1. Rendez-vous dans l'IP manager du back-office PrestaFence.
2. Créez une nouvelle règle de WAF.
3. Saisissez 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.

L'IP manager permet de créer des règles par IP, par chemin, ou un mix des deux. Whitelister un chemin (pour qu'aucune règle ne s'y applique) revient à appliquer une action Whitelist sur ce chemin :

1. Rendez-vous dans l'IP manager du back-office PrestaFence.
2. Créez une nouvelle règle de WAF.
3. Saisissez 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.

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.

Le WAF cible les tentatives d'accès direct et d'exfiltration de fichiers sensibles, par exemple :

• les fichiers de configuration (.env, parameters.php, settings.inc.php…) ;
• les fichiers de sauvegarde et dumps SQL exposés ;
• les logs et fichiers temporaires ;
• les accès directs à des scripts ou ressources qui ne devraient pas être servis publiquement.

Une partie de cette protection repose sur des RewriteRule déposées dans le .htaccess ; sur Nginx, une configuration équivalente est nécessaire (voir les FAQ Nginx). Cette liste est indicative et doit être alignée sur les règles réellement embarquées dans votre version.

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

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.

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)

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).

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

La double authentification (ou authentification à deux facteurs) introduit un élément physique en possession du titulaire du compte lors de l'authentification. Un e-mail, un SMS ou une application mobile sont considérés comme des facteurs forts : ils garantissent que le vol d'un identifiant et de son mot de passe ne suffit pas, à lui seul, à accéder à un compte administrateur.

Non. Nous voulons une solution fiable, robuste et conforme aux exigences PCI DSS (en SAQ-A). PrestaFence ne permet donc pas de contourner cette règle essentielle : chaque administrateur doit disposer d'un compte nominatif aux droits strictement proportionnés, ce qui suppose une adresse e-mail valide et accessible par son seul détenteur.

Si cette contrainte est trop forte, vous pouvez désactiver temporairement la double authentification — dans ce cas, nous recommandons d'ajouter une restriction du back-office par IP.

Pas encore, mais c'est prévu. Nous avons priorisé une solution simple, adoptable par tous les administrateurs. Les modules ne proposant que le TOTP obligent souvent un administrateur à configurer les QR codes des autres, ce qui complique le déploiement à grande échelle ; résultat, seule une minorité d'administrateurs l'active, ce qui rend la 2FA caduque.

Le bruteforce consiste à deviner un couple identifiant / mot de passe par soumission massive d'un formulaire d'authentification. PrestaFence ne dispose pas encore d'une protection bruteforce en back-office — elle est en revanche disponible en front-office.

Le credential stuffing consiste à utiliser des bases de couples identifiant / mot de passe volés pour détourner des comptes. La double authentification protège contre ce type d'attaque.

Vos clients utilisent peut-être le « vaulting » de leur carte bancaire, ou bénéficient d'un programme de fidélité avantageux. Des attaquants peuvent alors vouloir détourner des comptes clients pour exploiter les moyens de paiement enregistrés. Une double authentification du front-office constitue un moyen efficace de protéger vos clients (voir « Protéger mon front-office »).

Si vous disposez d'une IP fixe, vous pouvez créer une règle Exempt pour cette IP sur l'URI de votre back-office, avec une priorité 300. Remarque : cette procédure permet de bypasser la règle de double authentification. (Voir capture.)

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 de votre serveur (ou de votre transitaire) n'est pas dégradée. Pour le tester, déclenchez un envoi d'e-mail, par exemple une réinitialisation de mot de passe.
• Que le message n'est pas tombé dans les SPAM.
• Qu'un administrateur existe bien avec cette adresse e-mail — une simple erreur de saisie peut être à l'origine du problème.

Les codes ont par ailleurs une durée de validité limitée. Au-delà de 10 minutes, demandez-en un nouveau. Assurez-vous enfin que l'heure de votre serveur est correctement synchronisée (NTP), un décalage d'horloge pouvant invalider les codes. Si le problème persiste, purgez la session d'authentification concernée et réessayez.

Oui. La protection contre le bruteforce de l'authentification est activable en front-office.

Oui. Une double authentification est activable en front-office.

Attention, il est toute fois vraisemblable que l'adaptation du formulaire de saisie du code OTP pour votre thème soit nécessaire.

Oui. Un tableau des authentifications (réussies ou non) est disponible en back-office pour surveiller les activités suspectes : attaques bruteforce, échecs ou succès d'authentification, etc.

Vos clients ont pu être victimes de vols d'identifiants. Or, l'accès à leur compte personnel peut attiser les convoitises s'il renferme une valeur potentielle, notamment si :

• vous permettez l'enregistrement d'un moyen de paiement (CB…) ;
• vous proposez un portefeuille prépayé ou des cartes cadeaux ;
• vous vendez des produits dématérialisés facilement revendables (ebooks, logiciels…) ;
• vous proposez des abonnements accessibles en ligne.

Dans ces cas, la mise en place d'une double authentification est recommandée.

Un code d'authentification est envoyé par e-mail à la personne qui s'authentifie. Ce code est à reporter dans le formulaire qui suit la saisie du login / mot de passe.

Non. Le module PrestaFence ne permet pas nativement à un client de désactiver sa double authentification. Cependant, le hook actionPrestafenceFrontOtp permet à un développeur d'ajouter cette fonctionnalité.

Non, pas nativement. Cependant, le hook actionPrestafenceFrontOtp permet à un développeur d'ajouter cette logique.

Non. Le module ne gère pas nativement l'envoi par SMS ni le protocole TOTP (Google Authenticator ou équivalent). Cependant, le hook actionPrestafenceFrontOtp permet à un développeur d'ajouter ces alternatives.

Cette fonctionnalité modifiant l'authentification, le formulaire de saisie du code peut ne pas s'afficher correctement selon votre thème.

Testez impérativement la fonctionnalité avant la mise en production.

Le formulaire respecte le thème « Classic » de PrestaShop et s'insère de manière transparente dans le template _partials/login-form.tpl (voir la méthode TOTPPrefilter::addFrontOfficeTOTPField). Si votre thème ne modifie pas le formulaire de login dans ce template, surchargez ou remplacez les éléments du template modules/prestafence/views/templates/front/login-form-totp.tpl.

Pas toujours. Nous recommandons de coupler PrestaFence Bruteforce et OTP à une protection type Cloudflare Turnstile (ou équivalent), à appliquer sur vos pages d'inscription et de connexion.

Le hook actionPrestafenceFrontOtp public permet a un module tiers de personnaliser le comportement de la 2FA Front-Office de PrestaFence :

• desactiver le flow OTP de PrestaFence pour un contexte donne (`skip`)
• remplacer le handler OTP (`handler`) pour brancher une logique personnalisee

Le hook est execute dans `src/Hook/Common.php` et `src/Hook/FrontOtp.php`.

Parametres

• `customer` (`\Customer|null`)
• `null` lors de l'affichage/prepare de la page d'authentification
• instance `\Customer` pendant une tentative de login
• `handler` (passe par reference): instance du handler OTP à utiliser
• `skip` (passe par reference, bool): `true` pour bypass le traitement OTP PrestaFence

Moments d'appel (important)

Le hook est appelé a deux moments différents:

1. Dans `src/Hook/Common.php` (phase page d'authentification):

• `customer = null`
• le hook peut forcer la desactivation OTP via `skip`
• le handler peut preparer l'affichage (`actionDispatcher()`)

2. Dans `src/Hook/FrontOtp.php` (phase tentative de login):

• `customer = \Customer`
• le hook peut bypass le traitement OTP avant `processOtp()` via `skip`
• le hook peut substituer le handler OTP qui pilotera `processOtp()`, `needRedirect()` et `getAuthenticationLink()`

Exemple 1: bypass OTP selon votre contexte

public function hookActionPrestafenceFrontOtp(array $params)
{
    // Exemple: bypass OTP pour un groupe client specifique
    if (!empty($params['customer']) && (int) $params['customer']->id_default_group === 3) {
        $params['skip'] = true;
    }
}

Exemple 2: remplacer le handler OTP

use PrestafenceAddon\Handler\FrontOtp as PrestafenceFrontOtp;

class MyCustomFrontOtpHandler extends PrestafenceFrontOtp
{
    protected function getOtpProvider()
    {
        // Retourner votre provider OTP (ou conserver EMAIL)
        return parent::getOtpProvider();
    }
}

public function hookActionPrestafenceFrontOtp(array $params)
{
    $params['handler'] = new MyCustomFrontOtpHandler();
}

Contrat minimal du handler remplace

Le handler remplace doit rester compatible avec les appels realisés par PrestaFence:

• `actionDispatcher()`
• `processOtp(\Customer $customer, $customerLog, $authentication = null)`
• `needRedirect()`
• `getAuthenticationLink($reset = false)`

Le plus simple et le plus sur est d'étendre `PrestafenceAddon\Handler\FrontOtp` puis de surcharger uniquement ce dont vous avez besoin (pour définir votre propre solution de 2FA).

Recommandations

• Ne modifiez `skip` que pour des cas explicitement maitrisés.
• Si vous remplacez le handler, conservez la logique de sécurite et de redirection attendue.
• Testez les deux phases d'appel du hook:
  • affichage de la page d'authentification
  • tentative de login valide/invalide