Anti-spam formulaires : CAPTCHA et blocage des bots - Module PrestaShop

Le spam ne s’arrête pas à l’affichage du formulaire

Un CAPTCHA classique protège l’affichage du formulaire, pas son traitement. Un robot qui envoie directement une requête POST au contrôleur de contact, d’inscription ou de newsletter contourne le widget et dépose son message. C’est pourquoi des boutiques reçoivent encore du spam alors qu’un reCAPTCHA est actif. Les modules gratuits se limitent souvent à un fournisseur et à quelques formulaires, sans limite d’envoi, sans journal et sans moyen de vérifier ce qui se passe.

Anti-spam formulaires : CAPTCHA et blocage des bots place un contrôle côté serveur devant chaque formulaire protégé. L’envoi est examiné au tout début de la requête, avant que PrestaShop ou le module du formulaire ne le traite : un envoi refusé ne crée aucun compte, n’envoie aucun message, n’inscrit personne à la newsletter et ne publie aucun avis. Le module fonctionne sans compte tiers ni clé par défaut ; un CAPTCHA externe reste un choix, formulaire par formulaire.

Une protection à l’envoi, avant le traitement

Chaque formulaire protégé reçoit un jeton signé, un champ piège invisible et une durée minimale de remplissage. Le serveur vérifie la signature du jeton, l’âge de la page, le champ piège et les doublons avant d’accepter l’envoi. Un robot qui poste sans charger la page n’a pas de jeton valide ; un robot qui remplit tout le formulaire remplit aussi le champ piège.

• Jeton signé : lié au formulaire, à la boutique et à l’heure, il expire après 12 heures par défaut et se rafraîchit à la première interaction avec un formulaire ancien.
• Champ piège : caché hors de l’écran, jamais accessible au clavier, avec un nom tiré au hasard à l’installation.
• Durée minimale : de 0 à 30 secondes selon le formulaire, 1 à 3 secondes par défaut sur les formulaires sensibles, pour arrêter les envois instantanés.
• Doublons : un contenu identique renvoyé dans la fenêtre configurée est refusé, tandis qu’une correction après refus passe.

Un filet de sécurité protège les visiteurs réels : tant qu’un formulaire n’a jamais transmis les champs du module (thème ou module qui dessine le formulaire autrement), l’absence de jeton est journalisée sans bloquer, et le tableau de bord propose de tester la protection. Dès qu’un envoi valide a été vu, l’absence de jeton est refusée.

Les méthodes sans compte tiers sont activées par défaut

À l’installation, les sept formulaires natifs passent en mode protégé, sans CAPTCHA externe : contact, création de compte, connexion, formulaire client de la commande, mot de passe oublié, newsletter et avis produits. La boutique est donc protégée sans clé, sans abonnement et sans appel à un service externe. Aucun script de fournisseur n’est chargé tant que vous n’en choisissez pas un.

Le CAPTCHA que vous choisissez, formulaire par formulaire

Quand vous voulez une vérification supplémentaire, choisissez un fournisseur pour un formulaire donné : Google reCAPTCHA v2 (case à cocher ou invisible), reCAPTCHA v3 avec seuil de score, Cloudflare Turnstile, hCaptcha (normal, compact ou invisible) ou Friendly Captcha. Vous saisissez vos propres clés, le module ne les affiche jamais en retour, et un bouton de test vérifie qu’elles sont acceptées. Par défaut, le script du fournisseur n’est chargé que sur les pages qui contiennent un formulaire protégé par ce fournisseur, au premier contact avec le formulaire.

• Comportement si le fournisseur est injoignable : laisser passer (l’envoi passe et est journalisé comme non contrôlé) ou refuser, selon votre choix.
• Consentement : le script peut attendre l’accord du visiteur, avec le module Cookies RGPD ou un autre outil de consentement ; sans accord, le formulaire reste protégé par les contrôles natifs, ou affiche un message si vous choisissez de demander l’accord.
• Accessibilité : les variantes invisibles évitent une case à cocher supplémentaire ; un CAPTCHA visible peut gêner certains visiteurs, à vous de choisir.

Limitation de débit, listes et bannissement temporaire

Chaque envoi compte dans une fenêtre glissante par adresse IP et par adresse e-mail, avec des seuils réglables par formulaire. Au-delà, l’envoi est refusé ; après plusieurs avertissements, l’adresse est bannie temporairement sur tous les formulaires protégés. La navigation reste toujours possible : le module ne bloque jamais une page.

• Listes de blocage et d’autorisation : adresses IPv4 et IPv6, plages CIDR, adresses e-mail, domaines et motifs avec joker ; ajout manuel, import CSV et export CSV.
• Domaines jetables : une liste fournie à l’installation, que vous pouvez compléter ou réduire, et un contrôle MX facultatif avec cache.
• Une adresse présente dans les deux listes est autorisée : la liste d’autorisation l’emporte.

Observer avant de bloquer, et comprendre après

Le mode observation exécute tous les contrôles et journalise ce qui aurait été bloqué, sans rien refuser. Vous vérifiez pendant quelques jours que vos clients passent, puis vous activez la protection formulaire par formulaire. Le tableau de bord montre les envois acceptés, bloqués, observés, non contrôlés et exemptés, le taux de blocage, une courbe sur 30 jours, le détail par formulaire et par motif, et les adresses les plus bloquées.

Le journal des tentatives bloquées donne, pour chaque refus, le formulaire, le motif, la date, l’adresse masquée ou hachée et le domaine e-mail. Vous pouvez bloquer une adresse ou une plage, autoriser une adresse, bloquer un domaine ou lever un bannissement en un clic, puis exporter le journal en CSV. La purge est automatique au bout de 30 jours par défaut.

L’outil Tester ma protection lit la page du formulaire comme un visiteur, vérifie que les champs, le jeton et le script sont présents, envoie un envoi direct sans champs pour vérifier qu’il est refusé, et contrôle les clés du fournisseur choisi. Le résultat reste affiché jusqu’au test suivant.

Les formulaires couverts

Le module protège les sept formulaires natifs de PrestaShop, y compris la création de compte pendant la commande. Pour les formulaires d’autres modules, deux solutions : une règle par contrôleur, avec le champ qui marque l’envoi et le format de réponse attendu, ou l’API PHP documentée pour que le module appelle les contrôles depuis son propre code. Une règle prête à l’emploi couvre les alertes de disponibilité de ps_emailalerts.

La commande elle-même n’est jamais filtrée : ni le panier, ni le paiement, ni la confirmation, ni les adresses. Les seuils du formulaire client de la commande sont volontairement larges et sans durée minimale, pour ne jamais perdre une vente.

Vérification de l’e-mail à l’inscription, en option

Désactivée par défaut, elle ajoute un lien signé et expirant à l’inscription sur la page de création de compte. Un compte en attente ne peut pas se connecter avant confirmation et peut demander un nouveau lien. La boutique ne retient jamais un compte si elle n’envoie pas d’e-mails ou si l’envoi échoue, et un compte en attente reste librement accessible si le module est désactivé ou si la licence expire.

Exemptions et vie privée

Les employés connectés au back-office, les robots des moteurs de recherche vérifiés, les groupes de clients que vous exemptez, les adresses autorisées, les clients connectés (selon le formulaire) et les tâches planifiées ne sont pas contrôlés. Le journal ne contient jamais d’adresse en clair par défaut : l’adresse est masquée, une empreinte hachée sert aux listes et aux limites, et le domaine e-mail est conservé sans l’adresse complète. Vous choisissez la durée de conservation et pouvez exporter ou effacer les données via les hooks RGPD.

Le module vous aide à réduire le spam et à limiter les données collectées ; il ne certifie pas votre conformité au RGPD et ne remplace pas un conseil juridique. Les CAPTCHA externes ont leurs propres conditions et leur propre politique de confidentialité : c’est à vous de les mentionner dans votre politique et de choisir le consentement adapté.

Multiboutique, langues et licence

Réglages, formulaires, journal et statistiques sont propres à chaque boutique ; les entrées de listes peuvent être propres à une boutique ou partagées. L’interface et les messages existent en français, anglais, espagnol, italien et polonais ; les thèmes Classic et Hummingbird fonctionnent sans modification. La désinstallation conserve les données par défaut, avec une option pour les supprimer.

Le module fonctionne avec une licence WePresta valide. Sans licence valide, il se désactive : les formulaires ne sont plus contrôlés, aucun CAPTCHA n’est affiché et rien n’est journalisé, donc le spam peut revenir. Vos réglages, listes et journal sont conservés, et le module se réactive dès que la licence est valide.

Prérequis et limites

• PrestaShop 1.7.8, 8.0+ ou 9.0+ ; PHP 7.4 ou plus récent.
• Aucun compte payant obligatoire. Les fournisseurs de CAPTCHA sont facultatifs et demandent leurs propres clés ; Cloudflare Turnstile demande un compte Cloudflare.
• Une tâche planifiée (adresse avec jeton ou ligne de commande) exécute la maintenance quotidienne : purge du journal, des compteurs et des bannissements expirés.
• Les vérifications de CAPTCHA et le contrôle MX utilisent des appels réseau sortants ; sans réseau, le comportement que vous avez choisi s’applique.
• Aucun module ne peut promettre zéro spam. Ce module réduit fortement les envois automatisés et vous donne les moyens de voir et d’ajuster ; il ne remplace ni votre politique de confidentialité ni un conseil juridique.
• Une limitation trop stricte peut gêner des visiteurs derrière une même adresse (entreprise, opérateur mobile) : utilisez le mode observation et les listes d’autorisation avant d’activer.