Chez Heave Studio, nous accompagnons des boutiques WooCommerce, et il nous arrive de tomber sur des problèmes de fraude. Depuis quelques mois, les attaques de card testing via PayPal reviennent particulièrement souvent.
Le problème ne se résume pas à quelques commandes frauduleuses. Ces attaques coûtent de l’argent directement, ralentissent le site, polluent la base de données, et dans les pires cas elles peuvent mettre en danger le compte PayPal du marchand.
Cet article part de ce qu’on a vu sur le terrain : comment reconnaître une attaque de card testing, comment elle fonctionne techniquement sur WooCommerce, ce qui marche vraiment pour s’en protéger, et un cas client que nous avons traité récemment.
Qu’est-ce qu’une attaque de card testing
Le card testing (ou test de carte bancaire) consiste à tester automatiquement des numéros de cartes volés pour voir lesquels sont encore valides. Les fraudeurs lancent des bots qui passent des paiements de faible montant sur des sites e-commerce, en visant en général le produit le moins cher du catalogue.
WooCommerce est une cible pratique pour eux, parce que sa Store API permet d’automatiser tout le tunnel de commande sans jamais ouvrir la moindre page. Les cartes qui passent sont ensuite revendues sur le dark web ou réutilisées pour des fraudes plus importantes.
Comment savoir qu’une attaque est en cours
Sur les boutiques touchées, on retrouve presque toujours les mêmes signaux.
Un pic anormal de commandes, avec des dizaines ou des centaines de commandes en quelques minutes ou quelques heures, souvent la nuit ou pendant les heures creuses. Le produit le moins cher du catalogue est ciblé systématiquement, parce que les bots cherchent le prix le plus bas pour limiter le coût de chaque test. Le taux d’échec de paiement est très élevé, souvent au-dessus de 90%, puisque la plupart des cartes testées sont bloquées ou sans provision.
Côté données client, les emails sont générés automatiquement, avec des formats reconnaissables du type « [email protected] » ou des domaines jetables. Les adresses de facturation sont incohérentes : informations aléatoires, codes postaux qui n’existent pas, mélanges de données venant de sources différentes. Enfin, dans WooCommerce, l’attribution de source affiche « unknown » (inconnu), parce que les requêtes API n’envoient pas de referrer HTTP.
Pourquoi ces attaques posent un vrai problème
Impact financier direct
Selon le contrat PayPal, certaines tentatives peuvent générer des frais de traitement même quand le paiement échoue. Et quand une transaction frauduleuse aboutit, le chargeback qui suit entraîne :
- le remboursement intégral de la commande ;
- des frais fixes de 16 € par litige en zone euro, selon la grille tarifaire PayPal ;
- une dégradation de l’historique du compte marchand, avec un risque d’augmentation des frais à l’avenir.
Risque de suspension PayPal
Un volume anormal de transactions frauduleuses peut aussi conduire à des limitations temporaires du compte (plafonds de retrait réduits), à une mise sous surveillance avec contrôles renforcés, et dans les cas extrêmes à une suspension définitive. Réactiver un compte suspendu pour fraude peut prendre plusieurs semaines, ce qui met l’activité complètement à l’arrêt.
Impact technique et opérationnel
Les centaines de requêtes API par heure surchargent le serveur : le site ralentit, parfois au point de devenir inaccessible pour les vrais clients. Les milliers de commandes échouées encombrent la base, compliquent la gestion au quotidien et ralentissent les requêtes SQL. Le taux de conversion réel devient impossible à lire quand 95% des commandes sont frauduleuses. Et il reste le temps passé à analyser et nettoyer tout ça à la main, soit plusieurs heures de travail pour rien.
Comment les attaques exploitent WooCommerce
Les attaques modernes ne passent pas par le formulaire de checkout classique du navigateur. Elles tapent directement dans la Store API WooCommerce, avec une série de requêtes REST automatisées :
1. GET /wp-json/wc/store/products?orderby=price&order=asc → Récupération du produit le moins cher2. POST /wp-json/wc/store/cart/add-item → Ajout au panier3. POST /wp-json/wc/store/cart/update-customer → Injection des informations client factices4. POST /wp-json/wc/store/cart/select-shipping-rate → Sélection du mode de livraison5. POST /wp-json/wc/store/v1/checkout → Tentative de paiement avec la carte à testerTout ça s’exécute en quelques secondes, sans jamais charger une page HTML. C’est pour cette raison que les captchas classiques et le simple blocage d’IP ne servent à rien face à ce type d’automatisation. Les bots utilisent des proxies rotatifs et des VPN pour contourner les blocages, en changeant d’adresse toutes les 5 à 10 minutes. Bloquer à la main devient impossible à tenir.
Cas client Heave Studio : ce qu’on a déployé et les résultats
Voici un cas récent, avec le contexte, ce qu’on a mis en place et les limites de chaque mesure.
Le contexte de départ
Côté configuration technique :
- boutique WooCommerce en checkout classique (non-Blocks) ;
- produits physiques ;
- plusieurs passerelles de paiement, avec PayPal comme seule passerelle carte ;
- aucune intégration externe utilisant le Store API checkout ;
- serveur dédié correctement dimensionné ;
- compte invité autorisé.
Les symptômes observés :
- environ 160 tentatives de commandes frauduleuses sur 4 jours, avec des pics à 10 par heure ;
- le produit à moins de 50 € (le moins cher du catalogue) ciblé à chaque fois ;
- 100% de taux d’échec de paiement ;
- des emails au format « [email protected] » générés automatiquement ;
- un dashboard WooCommerce pollué ;
- une baisse logique du taux de conversion.
La solution mise en place
On a déployé une stratégie en plusieurs couches, adaptée au contexte de ce client.
1. Filtres anti-fraude PayPal en mode strict
L’idée est de bloquer les transactions suspectes directement chez PayPal, avant même qu’elles ne génèrent des frais. Concrètement, on a poussé les contrôles de risque au niveau maximum et activé tous les filtres de détection de fraude disponibles. Cette première passe a bloqué une partie des tentatives, mais pas toutes.
2. Rate limiting WooCommerce
Depuis WooCommerce 8.9.0 (décembre 2024), une limitation de débit pour la Store API est intégrée nativement, mais désactivée par défaut. On l’active dans WooCommerce > Réglages > Avancé > Fonctionnalités > Rate limit Checkout (disponible à partir de WooCommerce 9.6).
Pour la config appliquée (5 tentatives maximum par IP sur une fenêtre de 60 secondes), on ajoute ce snippet dans le thème enfant :
add_filter( 'woocommerce_store_api_rate_limit_options', function ( $options ) { return array( 'enabled' => true, // Active le rate limiting 'proxy_support' => true, // IMPORTANT si Cloudflare / reverse proxy 'limit' => 5, // Nombre max de requêtes 'seconds' => 60, // Fenêtre de temps (en secondes) );} );Il existe aussi un plugin communautaire pour gérer ces options via une interface.
À noter : WooCommerce a publié un article officiel sur la limitation du card testing qui reconnaît que la plupart des plugins CAPTCHA ne protègent ni le Checkout Block ni la Store API. Le rate limiting est leur réponse officielle au problème.
3. Blocage ciblé du checkout via Store API
Attention, mesure avancée qui ne s’applique que dans un contexte précis. Elle n’a de sens que si :
- le checkout WooCommerce Blocks n’est pas utilisé ;
- aucune application mobile ne dépend de l’API checkout ;
- aucune intégration externe (ERP, marketplace) n’utilise cet endpoint.
L’implémentation :
/** * Disable WooCommerce Store API checkout endpoint to stop card testing. * WARNING: Only if you DO NOT use WooCommerce Blocks checkout and have no legit integration relying on it. */add_filter( 'rest_pre_dispatch', function( $result, $server, $request ) { $route = $request->get_route(); // e.g. /wc/store/v1/checkout $method = $request->get_method(); // POST // Block only the Store API checkout routes if ( ( $route === '/wc/store/v1/checkout' || $route === '/wc/store/checkout' ) && $method === 'POST' ) { // Return a real REST response (JSON) instead of redirecting to a 404 page return new WP_Error( 'heave_store_api_checkout_disabled', 'Not found.', array( 'status' => 404 ) ); } return $result;}, 10, 3 );Les résultats
La combinaison de ces trois mesures a stoppé les commandes frauduleuses dès leur mise en place. Ces chiffres valent pour ce client précis et ne constituent pas une garantie universelle : chaque config WooCommerce est différente et demande une analyse à part.
Ce qui a rendu l’ensemble efficace, c’est justement l’empilement des couches. PayPal filtre en amont et bloque une part des transactions suspectes avant qu’elles n’atteignent le site. Le rate limiting freine fortement les bots qui passent cette première barrière. Le blocage de l’endpoint arrête ceux qui insistent. Un bot qui contourne la première couche se heurte à la deuxième, et s’il passe les deux, la troisième le stoppe. C’est cette redondance qui explique le résultat.
Nos recommandations pour tous types de boutiques
Si ta boutique utilise le checkout Blocks ou a des intégrations externes, le blocage complet de l’endpoint n’est pas jouable. Voici les alternatives.
1. Rate limiting WooCommerce (la solution universelle)
C’est notre première recommandation pour toute boutique WooCommerce récente. Intégré nativement depuis WooCommerce 8.9.0, il est compatible avec tous les checkouts (classique, Blocks, custom) et ne gêne pas les intégrations légitimes.
Pour l’activer : WooCommerce > Réglages > Fonctionnalités avancées > Rate limit Checkout. La config qu’on conseille reste 5 tentatives maximum par IP sur 60 secondes.
L’avantage, c’est que c’est natif, sans plugin tiers, compatible avec tous les checkouts et sans impact sur l’expérience utilisateur normale. La limite, c’est que ça reste moins efficace face à des proxies rotatifs massifs, et que ça peut gêner les environnements à IP partagée comme les bureaux d’entreprise.
2. Désactivation de PayPal Advanced Card Processing (ACP)
PayPal ACP permet aux clients de payer par carte directement sur le site, sans redirection. C’est précisément cette fonction que les bots exploitent le plus.
Pour la couper : WooCommerce > Réglages > Paiements, clique sur PayPal ou PayPal Payments, désactive « Advanced Card Processing » (ou « Traitement avancé des cartes »), puis enregistre. Après ça, les clients repassent par l’interface PayPal classique avec redirection pour payer. Le compromis, c’est un taux de conversion qui peut baisser légèrement.
3. Cloudflare : protection multicouche
Si ton site est déjà derrière Cloudflare (ce qu’on recommande pour tout site e-commerce), tu as plusieurs outils sous la main.
Sur le plan gratuit, tu peux activer le Bot Fight Mode pour la détection automatique des bots, créer des règles de pare-feu qui ciblent les chemins /wp-json/wc/store/*, et passer en mode « I’m Under Attack » pendant une attaque massive, ce qui déclenche un challenge JavaScript sur toutes les pages.
Sur les plans payants (à partir de 20 dollars par mois), tu ajoutes le rate limiting personnalisé (par exemple 5 requêtes par minute maximum sur les endpoints sensibles), le challenge automatique qui teste JavaScript pour les requêtes API suspectes, et des logs détaillés pour analyser les patterns d’attaque et affiner les règles.
Pour la config WAF, une règle qui marche bien : si l’URL contient « /wp-json/wc/store/checkout » ET que le pays n’est pas dans ta liste autorisée (par exemple France, Belgique, Suisse, Canada), OU que le score bot dépasse 30, alors applique un Challenge ou bloque la requête. À adapter à ta zone de vente réelle.
Ce qu’on déconseille à chaque fois
Le blocage d’IP simple ne mène nulle part. Les bots tournent sur des proxies rotatifs avec des milliers d’adresses, et tu joues au chat et à la souris indéfiniment. On a vu des clients bloquer plus de 500 IP en une semaine sans faire baisser les attaques.
Ne bloque pas les domaines email publics comme gmail.com ou outlook.com. Tu bloquerais au passage 40 à 60% de tes vrais clients, ce qui n’est pas acceptable.
Ne désactive jamais l’API REST WordPress dans son ensemble. Ça casse Gutenberg, beaucoup de plugins essentiels comme Yoast ou Contact Form 7, et toute appli mobile. À ne faire sous aucun prétexte.
Ne mise pas tout sur un captcha. Même le meilleur captcha du monde ne sert à rien si les bots n’ouvrent jamais les pages HTML. Les attaques API passent complètement à côté.
Désactiver le compte invité (guest checkout) ne change rien non plus. Les bots créent simplement des comptes automatiquement, on l’a constaté.
Enfin, attendre en se disant que « ça va passer » est risqué. Ces attaques peuvent durer des semaines, des mois, voire s’installer pour de bon.
Pour conclure
Les attaques de card testing sur WooCommerce et PayPal sont devenues courantes, et bien outillées. Pour y répondre correctement, il faut comprendre en détail le tunnel de paiement, la Store API WooCommerce et les contraintes propres à PayPal.
Chaque boutique est différente, donc on cale la protection sur la config réelle du site à chaque fois. Pour ce client, la combinaison filtres PayPal stricts, rate limiting WooCommerce et blocage de l’endpoint checkout a suffi à couper les commandes frauduleuses en 24 heures.
