Protection contre les bots, limites de requêtes et CAPTCHA dans PrestaShop

Ce que nous ferions

Nous identifierions le parcours défaillant et les requêtes responsables avant d'installer une autre couche de protection. La bonne approche dépend de votre boutique actuelle : versions de PrestaShop et de PHP, hébergement et proxys, thème, modules, intégrations, données enregistrées, marchés et personnes chargées d'examiner les refus. Conservez les contrôles fonctionnels et vérifiez si un module installé fournit déjà l'étape manquante.

Pour une boutique qui peine à servir les pages, commencez là où les requêtes peuvent être arrêtées avant PHP. Pour des soumissions indésirables sans problème de capacité, commencez par le formulaire concerné et sa validation côté serveur. Pour un compte ou une commande contestés, examinez les preuves avant de restreindre l'accès. Le tableau de décision ci-dessous vous aide à choisir la couche de départ.

Reproduisez les parcours pertinents sur une copie de préproduction privée avec votre thème, votre tunnel de commande et vos modules réels, isolée des emails clients, paiements réels et exports logistiques. Sauvegardez la configuration actuelle, répétez les tests de refus et de reprise, puis introduisez le changement dans un créneau de production convenu. Utilisez un essai de production de portée restreinte pour vérifier les adresses réelles des proxys, le trafic des robots et le comportement en périphérie que la préproduction ne peut pas reproduire, avec un responsable désigné et un moyen d'annuler la règle.

Pour évaluer l'exposition, le service PrestaShop Security Audit & Hardening Report fournit des constats hiérarchisés et un plan de correction ; la mise en œuvre fait l'objet d'un périmètre distinct.

Identifier les requêtes avant de les bloquer

Partez de l'action touchée : catégories lentes, connexions répétées, fausses inscriptions, messages indésirables ou accumulation de paniers vides. Relevez les horodatages, routes, paramètres de requête, codes de statut, temps de réponse et adresses réseau concernés. Comparez-les à l'activité des processus PHP, de la base de données et aux commandes légitimes.

Les robots de recherche, les outils d'aperçu de liens sociaux, les notifications de paiement, la supervision et les tâches planifiées peuvent tous constituer des automatisations utiles. L'extraction de données, le credential stuffing, les sondages de vulnérabilités, les faux comptes et les soumissions abusives nécessitent des contrôles différents. Un agent utilisateur déclaré, une adresse VPN, un réseau d'hébergement ou un pays ne prouve pas un abus.

Utiliser les journaux de requêtes pour mesurer les débits

Examinez les journaux du serveur web et du service en périphérie. Pour un journal d'accès classique au format combined, ces exemples comptent les requêtes enregistrées selon le premier champ d'adresse et le chemin demandé. Confirmez d'abord le format réel du journal ; une adresse de proxy dans le premier champ nécessite un traitement différent.

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Ces totaux couvrent le fichier, pas un intervalle de mesure du débit défini. Filtrez une fenêtre temporelle adaptée et distinguez ressources statiques, requêtes de pages, soumissions de formulaires et nouvelles tentatives avant de choisir les limites. Les sondages génériques tels que /wp-login.php ou /.env méritent un examen, mais ne démontrent pas une intrusion réussie.

Les statistiques natives peuvent donner des indices selon les modules statistiques installés. Dans Statistiques, examinez les panneaux disponibles Visiteurs en ligne, Provenance des visiteurs, Pages introuvables et Pages les plus vues pour repérer un changement à retracer dans les journaux de requêtes. La table des connexions n'est pas un journal HTTP complet : les robots reconnus peuvent être exclus et les enregistrements de connexion sont réutilisés sur une fenêtre de 30 minutes. La requête en lecture seule suivante compte les sessions de connexion IPv4 enregistrées pour la boutique 1, avec le préfixe d'exemple ps_.

SELECT INET_NTOA(c.ip_address) AS recorded_ipv4,
       COUNT(*) AS recorded_sessions
FROM ps_connections AS c
WHERE c.id_shop = 1
  AND c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY)
GROUP BY c.ip_address
ORDER BY recorded_sessions DESC
LIMIT 50;

Adaptez le préfixe des tables et le périmètre de boutique à votre installation. Exécutez les rapports en lecture seule via Paramètres avancés > Base de données > Gestionnaire SQL ou un outil de base de données autorisé. Ce stockage numérique historique des IP ne constitue pas un rapport complet du trafic IPv6. Les métadonnées de navigateur analysées dans les tables d'invités ne sont pas un journal User-Agent brut.

Les tables de visiteurs tierces peuvent aussi dédupliquer les observations. Le nombre de ces lignes mesure des enregistrements collectés, pas des requêtes, des visites ni une empreinte fiable d'appareil. Recoupez-les avec les journaux de requêtes avant d'agir.

Transformer les signaux d'alerte en diagnostic vérifiable

Conservez une fiche d'incident succincte avec un exemple de requête expurgé, son fuseau horaire, la route concernée et l'effet observé. Donnez le même intervalle à votre hébergeur et à votre développeur pour qu'ils comparent événements en périphérie, journaux d'accès et activité applicative sans échanger des fiches clients complètes.

Vérifier l'identité des robots et les adresses des proxys

Un bot peut envoyer Googlebot dans son User-Agent. Pour exempter un robot, faites correspondre son adresse aux plages IP actuelles publiées appropriées ou utilisez un DNS inverse confirmé par résolution directe.

1. Prenez l'IP du client d'origine dans un champ de journal fiable.
2. Effectuez sa résolution inverse.
3. Vérifiez le suffixe de domaine documenté par l'opérateur à une véritable frontière de domaine. Un nom d'hôte se terminant par googlebot.com.example.net n'appartient pas à Google.
4. Résolvez le nom d'hôte renvoyé et confirmez que l'adresse d'origine figure parmi les résultats.
5. Mettez en cache et actualisez les données de vérification, et gérez les échecs de résolution sans créer silencieusement une exemption permanente.

Utilisez la procédure de vérification des robots Google pour ses catégories de robots et ses fichiers actuels de plages IP. Les autres opérateurs ont leurs propres procédures. La vérification établit une identité, pas un droit à une capacité de rendu illimitée.

Configurez les proxys inverses de confiance avant d'activer les limites par IP. L'origine ne doit accepter les en-têtes d'adresse client transférée que d'infrastructures de confiance, et celles-ci doivent écraser les valeurs entrantes non fiables. La validation syntaxique d'une IP n'authentifie pas CF-Connecting-IP, X-Real-IP ou X-Forwarded-For.

Testez l'adresse vue par le service en périphérie, le serveur web, PHP et votre intégration de blocage. Vérifiez IPv4 et IPv6. Une mauvaise configuration peut regrouper tous les clients sous l'adresse d'un proxy ou laisser les clients choisir l'adresse journalisée.

Pour les règles par pays, confirmez la manière dont la localisation est obtenue. Un en-tête de pays émis par un service de confiance, un adaptateur GeoIP à jour et un cookie de pays enregistré n'ont pas la même fiabilité. Ne supposez pas qu'une ancienne API GeoIP fonctionne avec du code GeoIP2 moderne.

Choisir les contrôles au bon niveau

PrestaShop peut générer robots.txt dans Paramètres de la boutique > Trafic & SEO > SEO & URL. Examinez le contenu généré et vos routes réelles. Ne placez pas de secrets dans robots.txt et ne considérez pas un chemin interdit comme privé. L'inclusion dans le sitemap dépend de votre module de sitemap et de sa configuration.

Conservez les webhooks de paiement, la validation des commandes, les retours 3-D Secure et la supervision dans votre inventaire des routes. Consignez l'objectif, la méthode, la réponse attendue et le responsable de chaque route avant de changer son traitement. Vérifiez les signatures des prestataires et leurs exigences actuelles de transmission. Une exemption générale pour tout ce qui prétend être un client de paiement est dangereuse.

Une limite de débit doit utiliser un intervalle explicite et une charge mesurée. Configurez un statut de refus adapté, normalement HTTP 429 pour la limitation, et une réponse permettant une nouvelle tentative. Tenez compte des réseaux de bureau, opérateurs mobiles, outils d'accessibilité et clients automatisés légitimes. Comptez l'action que vous souhaitez limiter : inclure images produit et scripts dans une politique de connexion peut faire consommer le quota par un simple chargement de page. Un trafic distribué peut aussi saturer une route alors que chaque adresse reste sous sa limite individuelle.

Pour les limites applicatives, les tâches d'actualisation des robots vérifiés, les challenges JavaScript et la protection indépendante de capacité, utilisez la page d'aide de Security Revolution ; son pare-feu de requêtes est en mode surveillance par défaut, l'activation d'une fonctionnalité ne prouve donc pas à elle seule son application effective.

Contenir les requêtes coûteuses de recherche à facettes

Une requête de catégorie telle que /category-slug?q=Brand-Brand-A/Color-Red peut déclencher un travail de filtrage. De nombreuses combinaisons distinctes peuvent peu réutiliser le cache tout en occupant des processus PHP et des connexions à la base de données. Confirmez ce coût dans vos propres journaux et profils de requêtes.

Désactiver ps_facetedsearch peut retirer son interface et réduire le travail de filtrage. Cela n'empêche pas les clients de demander des URL déjà connues ni ces requêtes d'atteindre le contrôleur de catégorie. Un blocage global de tout paramètre q peut aussi casser la recherche, les routes de modules, les API et les filtres enregistrés des clients.

Cas pratique : serveur occupé, ventes inchangées

Supposons que vos journaux montrent des combinaisons de marques et de couleurs changeantes sur une catégorie, tandis que les processus PHP restent occupés. Regroupez les requêtes par catégorie autant que par URL complète : une longue liste d'URL différentes peut masquer une route coûteuse commune. Comparez les réponses filtrées et non filtrées et demandez à l'hébergeur où le temps est passé. Si les combinaisons se répètent rarement, ajouter chaque réponse à un cache de pages peut accroître le stockage et les écritures sans grande réutilisation.

Testez la règle sur cette catégorie confirmée, en conservant comme témoins un lien filtré direct représentatif et une session normale de filtrage dans le navigateur. Si les challenges en périphérie augmentent mais que le travail de l'origine reste élevé, examinez les requêtes qui passent encore : robots vérifiés, clients utilisant le marqueur AJAX, challenges réussis ou trafic direct vers l'origine. Ces preuves déterminent le changement suivant ; une hausse du nombre de challenges ne prouve pas à elle seule la disparition du goulot d'étranglement.

Créer une règle de portée restreinte en périphérie

1. Listez les chemins réels des catégories à facettes, y compris les sous-répertoires de boutique, langues et routes réécrites. Commencez par un petit ensemble explicite.
2. Ciblez les requêtes GET comportant le paramètre de facette pertinent. Testez aussi les paramètres vides et les valeurs répétées.
3. Décidez du traitement des robots vérifiés dans cette règle précise. Ne créez pas d'exemption générale pour des règles de sécurité sans rapport.
4. Vérifiez le filtrage AJAX. Renvoyer une page HTML de challenge à une requête attendant du JSON peut casser l'interface.
5. Essayez un Managed Challenge et examinez le comportement des clients ainsi que la charge résiduelle sur l'origine avant d'élargir la couverture.

Cette expression illustre une boutique dont le chemin de catégorie confirmé est exactement /en/12-home-accessories. Utilisez uniquement des chemins vérifiés pour votre boutique. Si les facettes sont encodées dans un chemin réécrit plutôt que dans un argument q, cette expression ne les reconnaîtra pas ; construisez et testez un ciblage pour ces routes réelles.

http.request.method eq "GET"
and http.request.uri.path eq "/en/12-home-accessories"
and len(http.request.uri.args["q"]) >= 0
and not cf.client.bot
and not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest")

La comparaison sur une clé absente donne faux lorsque q est absent. Consultez le comportement des valeurs dans le langage de règles Cloudflare. Le marqueur AJAX est falsifiable et certains clients AJAX légitimes l'omettent. Toute exception qui s'y fonde laisse un contournement possible. Une exception pour robot vérifié laisse également la charge de ce robot atteindre l'origine.

Les règles personnalisées et Managed Challenge sont disponibles dans toutes les offres Cloudflare. Les expressions régulières nécessitent Business ou Enterprise ; l'action Log des règles personnalisées nécessite Enterprise. Consultez la disponibilité des règles personnalisées. Sans Log, utilisez les analyses disponibles et un essai contrôlé de portée restreinte.

N'utilisez cf.bot_management.score qu'avec les droits Bot Management. Un essai possible cible les scores supérieurs à 1 et inférieurs à 30 ; traitez le score 1 séparément si nécessaire. Les scores décrivent l'automatisation, pas une intention malveillante. L'ancien score de menace n'est pas un substitut. Vérifiez les interactions entre fonctions Cloudflare avant de combiner les contrôles. Bot Fight Mode gratuit s'applique à tout le domaine et ne peut pas être exempté par des règles personnalisées.

Les challenges peuvent nécessiter une interaction, des cookies ou JavaScript. Testez les liens directs, les navigateurs mobiles et les outils de confidentialité. Les visiteurs qui réussissent un challenge peuvent encore générer du travail sur l'origine.

Fermer le contournement de l'origine

Faites passer les noms d'hôte web publics par le proxy du service en périphérie choisi. Gardez les enregistrements DNS de messagerie et autres services non HTTP configurés pour leur service réel. Auditez les enregistrements révélant l'origine web et limitez l'accès HTTP/HTTPS à l'origine aux adresses actuelles publiées du service en périphérie et aux accès opérationnels strictement justifiés. Préservez le renouvellement des certificats, les contrôles de santé et l'accès de retour arrière. Utilisez un HTTPS valide entre le service en périphérie et l'origine.

Réexaminez l'accès des robots, la visibilité dans les moteurs de recherche et les visites référentes utiles après les changements. Si le filtre existant fonctionne pour les acheteurs, conservez-le pendant la validation des contrôles de trafic. Envisagez une autre architecture de filtrage lorsque la navigation du catalogue doit aussi être revue, avec des pages de destination sélectionnées délibérément plutôt que des combinaisons indexables arbitraires. Elle peut réduire la découverte de combinaisons arbitraires, mais les anciennes URL et les points d'accès AJAX nécessitent toujours des contrôles ; utilisez la page d'aide de Filter Revolution pour le routage et le processus de pages SEO de ce module.

Protéger le serveur d'origine sans WAF en périphérie

Utilisez des limites serveur si vous contrôlez Apache ou Nginx, ou demandez à votre hébergeur de les appliquer. Apache .htaccess permet des conditions de requête adaptées lorsque les surcharges de configuration sont autorisées ; les modules de limitation comme mod_evasive nécessitent leur configuration serveur ou d'hôte virtuel prise en charge. Les blocages par User-Agent peuvent exprimer une politique vis-à-vis des robots, mais les agents vides ou nommés ne sont pas intrinsèquement malveillants.

Dans Nginx, limit_req_zone se place dans le contexte http. Appliquez limit_req là où la requête coûteuse est réellement traitée. Les URL simplifiées peuvent rediriger en interne vers index.php ; testez donc le bloc location final et les paramètres de route. Voici des exemples de directives à intégrer à une configuration existante, pas un bloc serveur complet de remplacement :

# http context: illustrative measured-policy starting point
limit_req_zone $binary_remote_addr zone=shop_requests:20m rate=10r/s;

# In the applicable request-processing context
limit_req zone=shop_requests burst=40;
limit_req_status 429;
limit_req_dry_run on;

Utilisez la documentation Nginx de limitation des requêtes pour vérifier la prise en charge et l'héritage des directives. Avec limit_req_dry_run on, les requêtes excédentaires sont enregistrées mais pas refusées. Après examen des journaux et des parcours légitimes, définissez limit_req_dry_run off, testez la configuration et ne rechargez qu'une configuration valide, en conservant la précédente pour revenir en arrière. La connexion et les filtres coûteux peuvent nécessiter des politiques distinctes ; une expression régulière pour /search ne couvre pas toutes les requêtes de catégories avec q.

Pour fail2ban, journalisez un événement explicite d'échec d'authentification côté serveur et testez le filtre sur de véritables connexions échouées et réussies. Incluez une simple erreur de mot de passe suivie d'une tentative réussie et confirmez comment une personne autorisée lève un blocage erroné. La connexion client native peut renvoyer un formulaire d'erreur avec HTTP 200. Un filtre ne recherchant que les POST de connexion retournant 401 ou 403 peut manquer les échecs. Ne journalisez jamais les mots de passe ni les secrets CAPTCHA.

Une redirection applicative ciblée en solution de repli

Si une URL directe de facette sélectionnée doit aboutir à sa catégorie sans filtre, un développeur peut implémenter une redirection précoce dans Dispatcher. Elle démarre tout de même PHP et est moins utile contre l'épuisement des connexions qu'un contrôle en périphérie ou au niveau serveur.

1. Résolvez ou ciblez explicitement la catégorie de la boutique et de la langue courantes. Limitez l'intervention aux requêtes GET avec le paramètre de facette concerné.
2. Excluez la recherche et les routes de modules ou d'API. Si vous préservez les requêtes AJAX, testez leur marqueur réel et acceptez que les bots puissent le copier.
3. Analysez REQUEST_URI, retirez uniquement q et reconstruisez la requête avec http_build_query(). Conservez les autres paramètres, le chemin de base de la boutique et le préfixe de langue.
4. Utilisez l'origine configurée de la boutique, empêchez les boucles et arrêtez le traitement après la redirection. Sinon, poursuivez la distribution normale.
5. Testez avec une redirection temporaire. N'utilisez une 301 permanente que si la suppression de la destination filtrée est intentionnelle. Examinez les surcharges Dispatcher existantes et reconstruisez l'index de classes pertinent après le déploiement.

Les liens enregistrés perdent leurs filtres sélectionnés dans ce périmètre. Examinez les pages de filtres indexées utiles et établissez délibérément leurs correspondances plutôt que de supposer qu'aucune combinaison n'a de valeur dans les moteurs. Combiner une redirection et une règle en périphérie retire toujours le filtre après qu'un client a été autorisé à passer.

Protéger les formulaires par une validation côté serveur

Choisissez les formulaires selon les abus observés : inscription, contact, connexion, réinitialisation de mot de passe, newsletter, avis ou commande. La recherche et l'ajout au panier peuvent aussi subir des abus de ressources, même si un CAPTCHA interactif n'est pas automatiquement le bon remède.

Les formulaires standard n'intègrent pas tous un CAPTCHA, mais ne sont pas dépourvus de contrôles. La récupération du mot de passe comprend des vérifications de délai ; certaines versions du module de contact officiel utilisent un champ piège et un jeton expirant. Conservez ces contrôles en ajoutant une autre couche. Testez le remplissage automatique et les outils d'assistance avec tout champ piège ajouté : un champ caché renseigné mérite une validation plutôt qu'une supposition sur son auteur.

Sélectionnez le fournisseur et le mode, créez les clés correspondantes dans sa console et saisissez-les dans la configuration du module. Activez la protection des formulaires visés, puis effectuez les tests de soumission valide et de refus ci-dessous. La clé de site est publique ; gardez la clé secrète sur le serveur. Utilisez le bon type de clé, le bon environnement et la bonne configuration des noms d'hôte. Enregistrer un domaine racine reCAPTCHA couvre ce domaine et ses sous-domaines de premier niveau, dont www ; les domaines sans rapport nécessitent leur propre configuration autorisée. Suivez les règles de domaine de Google et celles, distinctes, des autres fournisseurs.

Le serveur doit vérifier le jeton et le contexte attendu avant de créer un compte, envoyer un e-mail, abonner une adresse ou authentifier un client. Vérifiez la réussite, le nom d'hôte, l'action et le score selon le cas. Ne faites jamais confiance au seul indicateur de réussite côté client ou à un badge affiché.

Traitez séparément la connexion des clients et celle des employés. Un challenge fonctionnel en front-office ne dit rien de l'accès au back-office ; l'authentification du personnel exige ses propres vérifications et sa procédure de récupération.

Pour les développeurs, vérifiez le contrat natif exact de chaque version prise en charge. L'inscription moderne combine les résultats de actionSubmitAccountBefore sous forme booléenne. La connexion client native appelle actionAuthenticationBefore mais n'utilise pas sa valeur de retour comme refus. Enregistrer simplement un hook au nom similaire ne suffit pas. La connexion lors de la commande, l'inscription des invités, les formulaires AJAX et les thèmes personnalisés nécessitent leur propre couverture des routes.

L'inscription native d'un compte ne nécessite généralement pas de lien d'activation par e-mail. L'e-mail de bienvenue, la vérification du compte et la double confirmation de newsletter sont des processus distincts.

Pour les paramètres du fournisseur, les formulaires pris en charge, le repli facultatif de v3 vers v2 et le chargement conditionnel des scripts, utilisez la page d'aide de reCAPTCHA & hCaptcha Protection. La couverture annoncée concerne contact, connexion client, inscription et newsletter, sélectionnés séparément ; ces options ne certifient pas toutes les intégrations de commande, de réinitialisation de mot de passe ou d'avis. Le repli annoncé affiche une case à cocher à la tentative suivant un score faible et nécessite une paire distincte de clés de repli. Vérifiez que votre version installée le propose et que le client peut effectuer cette tentative suivante.

Cas pratique : inscription protégée, faux comptes persistants

Supposons que le formulaire autonome de création de compte rejette un jeton absent, mais que de nouveaux comptes indésirables apparaissent encore. Retracez un exemple de création jusqu'à sa route réelle. Un tunnel de commande personnalisé peut soumettre les données d'invité ou de compte via un autre point d'accès, tandis qu'un importateur ou une intégration peut créer des clients sans utiliser le formulaire public d'inscription. Confirmez le comportement attendu de cette route plutôt que de relever le seuil de score d'un autre formulaire.

Pour le spam de contact, distinguez de même un message créé via le formulaire de la boutique d'un spam envoyé directement à votre boîte mail. Un challenge de formulaire ne peut pas intercepter les emails directs. Une fois la route identifiée, répétez-y une soumission valide et un test de refus en vérifiant le client, le message ou la file d'emails obtenus.

Tester les refus, les pannes et les clients légitimes

Exécutez la matrice suivante en préproduction pour chaque formulaire visé et chaque route prise en charge. Utilisez des comptes de test et des réceptacles d'e-mails, et vérifiez les effets produits autant que la réponse visible.

Testez avec un clavier, un lecteur d'écran, une connexion mobile et des outils de confidentialité. Conservez les données saisies lorsque c'est sûr et proposez un moyen de contact utile, comme l'assistance mypresta.rocks pour les problèmes liés à ses modules.

Ajustez les scores selon leur distribution par action dans votre boutique, les abus et les taux d'achèvement légitimes. Un seuil comme 0,5 est une valeur d'essai, pas un réglage universellement sûr. Ne supposez pas qu'un navigateur, un VPN ou une vitesse de frappe particulière explique un score faible.

Mesurez les requêtes fournisseur et les ressources transférées dans un navigateur avant de choisir les règles de chargement. Le chargement global peut ajouter du travail sur des pages sans formulaire protégé ; le chargement conditionnel doit tout de même couvrir les formulaires de pied de page, les fenêtres modales et les formulaires insérés par AJAX. Aucun volume JavaScript fixe ni gain de conversion ne s'applique à toutes les configurations.

Surveillez les formulaires soumis, les refus côté serveur, les faux positifs, les résultats de spam et les commandes finalisées sur des périodes comparables. Distinguez vues, tentatives, soumissions acceptées et résultats indésirables lorsque vos rapports le permettent, et notez les campagnes ou autres changements de clientèle. Une baisse ou une hausse du spam ne prouve pas à elle seule la bonne intégration. Si les vérifications du fournisseur réussissent mais que les messages acceptés restent indésirables, examinez le contenu et les habitudes de soumission ; un challenge vérifié ne garantit pas une demande utile.

Appliquer des restrictions et une conservation proportionnées

Une restriction IP vise une adresse réseau, pas une personne. Les bureaux, universités, réseaux d'opérateurs, VPN et proxys peuvent desservir des clients sans lien entre eux. Un visiteur abusif peut changer d'adresse. Les métadonnées de navigateur ne constituent ni une identification unique ni la preuve que plusieurs comptes appartiennent à une même personne.

Utilisez l'action, l'expiration et la plage d'adresses les plus restreintes adaptées au besoin. Une adresse exacte est plus ciblée que 203.0.113.0/24 ; un joker ou une plage arbitraire peut toucher de nombreux visiteurs. Vérifiez la prise en charge d'IPv6 par l'intégration avant de supposer que ses règles de correspondance IPv4 s'y appliquent.

Une restriction de commande peut inclure les routes du panier, tandis qu'une restriction d'authentification peut couvrir les pages de compte, d'identité et de mot de passe. Les routes personnalisées de commande et de paiement peuvent se comporter différemment. Testez les utilisateurs bloqués et autorisés de bout en bout et conservez un accès opérationnel contrôlé pour votre équipe et la supervision.

Confirmez le module de visiteurs installé et son schéma avant d'interroger les tables mprvc_*. Pour les paramètres de métadonnées, de restriction, de champs et d'expiration propres au produit, utilisez la page d'aide de Customer Extra Info (IP Ban) ; l'expiration d'un blocage désactive une restriction sans effacer elle-même l'enregistrement.

Documentez l'objectif, la raison, le responsable de validation et la durée de conservation. Ne collectez que le nécessaire et distinguez les champs facultatifs des données toujours enregistrées par l'intégration. Supprimez les informations obsolètes par un processus de conservation délibéré, en préservant les preuves d'incident lorsque cela est requis.

Un pays hors de votre zone de livraison ne justifie pas automatiquement de refuser l'accès au site. Les règles européennes limitent les restrictions et redirections fondées sur la nationalité et la résidence ; appliquez des mesures de sécurité légales et proportionnées et examinez les commandes existantes et les obligations contractuelles. Consultez le règlement (UE) 2018/302.

Cas pratique : un bureau partage l'adresse à bloquer

Si des inscriptions factices répétées proviennent d'une adresse également utilisée par un client professionnel légitime, comparez les heures de création et les chemins des requêtes avant d'agir. Préférez une règle sur l'action d'inscription détournée à une restriction de toute la boutique lorsque l'intégration le permet. Vérifiez ce qu'une règle limitée à l'authentification couvre réellement : elle peut aussi empêcher la connexion ou la récupération de mot de passe de ce client. Testez le parcours d'un collègue autorisé autant que la requête indésirable, fixez une date de réexamen et indiquez à l'assistance comment signaler un refus erroné.

L'accès en maintenance est un contrôle différent

La liste d'IP autorisées dans Paramètres de la boutique > Général > Maintenance permet aux visiteurs listés d'accéder à une boutique en mode maintenance. Ce n'est pas une liste de blocage pour écarter un contrevenant d'une boutique ouverte. Utilisez le contrôle dont le périmètre correspond à l'action à restreindre.

Consentement et confidentialité des fournisseurs

La CNIL distingue les opérations CAPTCHA exclusivement destinées à la sécurité de celles qui servent aussi des finalités supplémentaires exigeant un consentement. Lorsque le consentement est requis, son refus ne doit pas créer de contournement de sécurité : prévoyez un contrôle alternatif ou complémentaire ne nécessitant pas ce consentement. Changer simplement de fournisseur ne résout pas les obligations de protection des données et de transferts internationaux. Suivez les instructions CAPTCHA de la CNIL, question 17.

Un hook nommé displayGDPRConsent peut être un emplacement d'affichage de widget. Son nom ne garantit pas un blocage préalable au consentement. Vérifiez les requêtes de scripts avant le consentement, après refus et après retrait, et testez aussi le parcours serveur.

Gérer les paniers vides et évaluer le résultat

Un GET de catégorie ne crée pas automatiquement un panier persistant pour chaque visiteur. Le traitement natif d'ajout au panier vérifie d'abord les produits et quantités. Un ajout valide, un module ou un autre parcours de session peut créer un panier ; un échec ultérieur peut le laisser vide. Des paniers anonymes ou vides ne prouvent pas à eux seuls une activité de bots ou des ventes perdues.

Recoupez les heures de création des paniers avec les requêtes et identifiez le composant qui les enregistre. Les contrôles de trafic peuvent réduire les requêtes qu'ils interceptent, mais ne garantissent ni l'arrêt de la croissance des paniers ni la suppression des enregistrements existants.

Utilisez des sauvegardes et un nettoyage limité par l'âge qui tient compte des dépendances. Préservez les paniers liés aux commandes, les paniers légitimes récupérables, les personnalisations, les fichiers associés et les données d'incident nécessaires. Masquer le bruit confirmé dans les vues opérationnelles est distinct de le supprimer.

Réexaminez les limites après les changements d'URL, de thème, de modules de paiement ou de trafic. Confirmez que les robots connus, la supervision, les notifications de paiement, les clients derrière des réseaux partagés et les outils d'accessibilité fonctionnent toujours. Suivez ensemble les requêtes rejetées, les faux positifs, les temps de réponse et la capacité de rendu.

Les chiffres historiques des robots donnent du contexte, pas une prévision de capacité. Cloudflare a mesuré une croissance agrégée de 18% des robots de recherche et d'IA entre mai 2024 et mai 2025, avec un pic en avril 2025 supérieur de 32% à mai 2024. Dans sa ventilation par robot, les requêtes Googlebot ont augmenté de 96% et leur part est passée d'environ 30% à 50% ; les requêtes GPTBot ont augmenté de 305%, avec une part passant de 2,2% à 7,7%. ClaudeBot a baissé de 46% et Bytespider de 85% ; la part de PerplexityBot est passée de moins de 0,01% à 0,2%. La série agrégée ne suivait pas une hausse continue. Consultez l'analyse datée de Cloudflare sur les robots. Dimensionnez vos contrôles selon votre propre trafic actuel.

Menez ce travail parallèlement aux mises à jour, à une authentification forte du back-office et à la supervision. Utilisez le guide de sécurité pour la liste de vérification générale et le guide de réponse à une intrusion si vous soupçonnez une intrusion.

Lancer un changement réversible et le transmettre à l'équipe

1. Consignez la référence initiale. Sauvegardez les routes concernées, les réglages actuels et les preuves du problème. Convenez de l'amélioration attendue et des échecs clients ou d'intégration imposant un retour arrière.
2. Modifiez un périmètre défini. Répétez les tests pertinents en préproduction et conservez la configuration précédente. Évitez de modifier ensemble la règle en périphérie, le seuil CAPTCHA et les restrictions de visiteurs, ce qui complique l'attribution d'un refus.
3. Vérifiez les différences de production. Confirmez les noms d'hôte réels, les clés fournisseur, la confiance des proxys, les restrictions d'origine et les fonctionnalités disponibles de l'offre en périphérie avant la bascule prévue.
4. Effectuez l'essai en production de portée restreinte. Utilisez des parcours clients contrôlés et les vérifications de retours prises en charge par les prestataires. Examinez la réponse réelle et son effet ; un accueil fonctionnel ne prouve pas que le paiement, la connexion ou les webhooks fonctionnent encore.
5. Examinez les deux résultats. Comparez le travail restant de l'origine et les soumissions indésirables aux parcours légitimes terminés et aux signalements à l'assistance. Si un parcours valide échoue, annulez le changement responsable et examinez la requête enregistrée.
6. Laissez une fiche d'exploitation. Consignez le périmètre final, les exceptions, le responsable du réexamen, sa date et les instructions de retour arrière. Assurez-vous qu'une autre personne autorisée peut accéder au panneau de contrôle si l'administrateur habituel est bloqué ou absent.

Questions à poser à votre développeur ou agence

• Quel composant reçoit chaque requête concernée, et quelles preuves la relient au problème ?
• À quel endroit l'adresse client d'origine est-elle considérée comme fiable, et un en-tête entrant peut-il modifier l'adresse journalisée ou bloquée ?
• Quelles routes et quels effets ont été testés avec notre thème, notre tunnel de commande et nos versions de modules installés, y compris les soumissions directes et les pannes fournisseur ?
• Quels clients automatisés et clients partageant un réseau ont été vérifiés, et quelle charge reste hors du périmètre de la règle ?
• Qui peut annuler le changement, où sont les résultats expurgés et quels futurs changements de routes ou d'intégrations nécessitent un nouveau test ?

Questions des commerçants

Mon hébergeur recommande un serveur plus puissant. Faut-il accepter ?

Demandez des preuves du goulot d'étranglement et des requêtes responsables. Une capacité supplémentaire peut être justifiée par une demande légitime, mais comparez la charge restante après un essai de contrôle du trafic ciblé. Un serveur plus puissant seul laisse les routes indésirables accessibles.

Pourquoi un client rencontre-t-il un échec uniquement sur téléphone ?

Demandez l'heure, la page concernée et l'erreur visible sans recueillir de mots de passe ni de jetons. Retracez cette tentative dans le service en périphérie, le serveur et l'intégration du formulaire, puis reproduisez le parcours avec le navigateur et la connexion mobiles concernés. Changer tous les réglages de protection avant d'identifier la couche responsable du refus peut masquer la cause.

Peut-on tester la protection en submergeant le paiement en production ?

Utilisez un plan de test convenu et borné sur un environnement isolé. Confirmez qui contrôle le test, quelles limites l'arrêtent et comment commandes, emails et paiements restent isolés. La validation en production doit utiliser les parcours contrôlés convenus avec votre hébergeur et vos prestataires d'intégration.

Un CAPTCHA réussi signifie-t-il qu'une commande peut être expédiée sans risque ?

Non. Il vérifie le challenge configuré du formulaire, pas la propriété du compte, la légitimité du paiement ou le risque de livraison. Conservez les contrôles de commande et de paiement nécessaires à votre activité avant de libérer les marchandises.