Les vulnérabilités spécifiques au e-commerce : race conditions, manipulation de prix, abus de coupons. Comment les détecter et s'en protéger.
Jordan Fredj
January 5, 2026
11 min
Loading...
Jordan Fredj
Fondateur, Hacksessible
Le secteur du e-commerce est expose a des vulnérabilités spécifiques qui vont bien au-dela des failles web classiques. Les race conditions, la manipulation de prix, l'abus de coupons et les contournements de logique panier sont des attaques qui ciblent directement la logique metier des plateformes de vente en ligne. Ces vulnérabilités sont particulierement dangereuses car elles ont un impact financier direct et sont rarement détectées par les scanners de sécurité traditionnels. Cet article detaille ces menaces spécifiques et les stratégies de defense adaptees.
Une race condition survient lorsque le comportement d'un système depend de l'ordre ou du timing d'evenements non controles, typiquement des requetes concurrentes. Dans le contexte du e-commerce, les race conditions permettent des attaques avec un impact financier direct.
Scenario classique : un coupon de reduction est cense etre utilise une seule fois. L'application verifie si le coupon est deja utilise, puis l'applique a la commande. Si un attaquant envoie 10 requetes simultanees pour appliquer le meme coupon, la verification "est-ce que ce coupon est deja utilise ?" peut retourner "non" pour les 10 requetes avant que la première n'ait marque le coupon comme utilise. Resultat : le coupon est applique 10 fois, generant une reduction massive non autorisee.
Ce type de race condition est extremement courant. La plupart des implementations naives de verification "coupon deja utilise" sont vulnerables car elles suivent un pattern "read-check-write" sans mecanisme de verrouillage. L'exploitation est triviale : quelques lignes de code suffisent pour envoyer des requetes concurrentes via des outils comme Burp Turbo Intruder ou un simple script Python avec asyncio.
Un autre scenario frequente implique la gestion des stocks. Un produit en edition limitee a 1 exemplaire restant. Plusieurs acheteurs envoient des requetes d'achat simultanement. L'application verifie le stock (1 disponible), valide l'achat, puis decremente le stock. Si plusieurs requetes sont traitees simultanement, le stock peut etre vendu plusieurs fois avant que le compteur ne soit decremente. L'impact va au-dela de la perte financiere : il cree des problèmes de logistique, de satisfaction client, et de reputation.
Les portefeuilles virtuels, credits de parrainage, et systèmes de points de fidelite sont des cibles de choix. Si un utilisateur a 100 euros de credit, il peut tenter d'envoyer simultanement plusieurs requetes pour depenser ces 100 euros, depassant potentiellement son solde reel. Ce type de race condition peut etre systematiquement exploite pour generer de la valeur fictive.
La manipulation de prix est une categorie de vulnérabilités ou un attaquant modifie le prix d'un produit dans les requetes envoyees au serveur. Bien que cela semble simpliste, de nombreuses plateformes e-commerce sont vulnerables a ce type d'attaque.
Certaines implementations incluent le prix du produit dans les donnees envoyees par le client (formulaire HTML cache, cookie, parametre de requete). Un attaquant peut simplement modifier ce prix avant de soumettre la commande. La regle d'or : ne jamais faire confiance aux donnees du client pour les calculs financiers. Tous les prix doivent etre recalcules cote serveur a partir de la base de donnees au moment de la validation de la commande.
Des manipulations plus subtiles ciblent la logique du panier. Par exemple : ajouter un produit au panier, obtenir un prix reduit grace a une promotion, puis modifier le contenu du panier tout en conservant le prix reduit. Ou encore : manipuler les quantites pour declencher des remises de volume, puis reduire la quantite a l'etape de paiement tout en conservant le prix unitaire reduit. Ces attaques exploitent des failles dans la coherence des calculs entre les étapes du tunnel d'achat.
Les plateformes multi-devises sont exposees a des manipulations liees aux conversions et aux arrondis. Un attaquant peut exploiter les differences d'arrondi entre les devises pour generer de petits gains qui, multiplies par des milliers de transactions, deviennent significatifs. Ce type d'attaque est difficile a détectér car chaque transaction individuelle semble normale.
Au-dela des race conditions sur les coupons, d'autres formes d'abus existent. Le coupon stacking (empilement de coupons non prevus pour etre combines) peut resulter en des reductions excessives. La generation de coupons via des patterns previsibles (si les codes suivent un schema comme PROMO2026-001, PROMO2026-002) permet d'enumerer et d'utiliser des codes destines a d'autres clients. L'abus de programmes de parrainage (creation de faux comptes pour generer des credits de parrainage) est egalement frequente.
Ces abus sont difficiles a détectér car chaque transaction individuelle semble legitime. Seule une analyse comportementale ou un test de sécurité approfondi peut les identifiér. Les agents IA d'Hacksessible sont particulierement efficaces pour ce type de détection car ils peuvent tester systematiquement les combinaisons de coupons, les scenarios d'empilement, et les patterns de codes.
Les integrations avec les systèmes de paiement (Stripe, PayPal, Adyen) sont des zones a risque si elles sont mal implementees. Plusieurs types de contournements sont courants.
La validation insuffisante du webhook de paiement permet a un attaquant de forger une notification de paiement reussi sans avoir réellement paye. Si l'application ne verifie pas la signature du webhook ou ne reconcilie pas le montant paye avec le montant attendu, la commande est validee sans paiement.
Le contournement du tunnel de paiement peut se faire en accedant directement a l'endpoint de confirmation de commande, sans passer par l'etape de paiement. Si le serveur ne verifie pas qu'un paiement valide a ete effectue avant de valider la commande, l'attaquant obtient sa commande gratuitement.
La modification du montant post-creation de l'intention de paiement est une autre variante : l'attaquant cree un panier a 100 euros, obtient une intention de paiement Stripe a 100 euros, puis modifie son panier pour y ajouter des produits supplementaires avant de finaliser le paiement de 100 euros.
Toutes les vulnérabilités decrites dans cet article ont un point commun : elles sont des failles de logique metier, pas des failles techniques classiques. Il n'y a pas de pattern technique a détectér par signature. Un scanner de vulnérabilités ne comprend pas la logique de votre système de panier, de vos coupons, ou de votre integration de paiement. Il ne sait pas qu'un prix devrait etre X et pas Y, ou qu'un coupon ne devrait pas pouvoir etre applique deux fois.
Pour les race conditions : utilisez des mecanismes de verrouillage au niveau de la base de donnees (SELECT FOR UPDATE, transactions SERIALIZABLE). Implementez l'idempotence pour les operations critiques. Utilisez des tokens anti-replay pour les operations financieres. Testez spécifiquement les scenarios de concurrence dans votre suite de tests.
Pour la manipulation de prix : ne faites jamais confiance aux prix envoyes par le client. Recalculez tous les montants cote serveur au moment de la validation. Verifiez la coherence entre le montant paye et le montant attendu. Implementez des alertes pour les transactions avec des montants anormaux.
Pour les abus de coupons : generez des codes aleatoires non previsibles. Implementez les verifications avec des mecanismes de verrouillage. Limitez le nombre de coupons par compte et par adresse IP. Surveillez les patterns d'utilisation anormaux.
Les outils comme Burp Suite Turbo Intruder permettent d'envoyer des requetes concurrentes avec un timing precis. L'approche consiste a identifiér les operations critiques (application de coupon, achat, transfert de credit), puis a envoyer des requetes identiques en parallele et a observer si le système maintient ses invariants. Le pentest automatisé par IA automatisé ces tests de maniere systematique sur tous les endpoints critiques.
Les frameworks geres (Shopify) sont généralement mieux proteges car le fournisseur gere la sécurité du noyau. Les frameworks self-hosted (Magento, PrestaShop, WooCommerce) dependent de la configuration et des extensions installees. Les extensions tierces sont souvent la source des vulnérabilités les plus critiques. Dans tous les cas, les personnalisations et les integrations custom sont des zones a risque qui nécessitént des tests spécifiques.
L'impact depend du volume de transactions et de la duree d'exploitation. Les abus de coupons et les race conditions peuvent generer des pertes de plusieurs dizaines de milliers d'euros par mois sur une plateforme a fort trafic. Les manipulations de prix peuvent aller beaucoup plus loin si elles ne sont pas détectées. L'investissement dans des tests de sécurité spécifiques au e-commerce est largement rentabilise par la prevention de ces pertes.
Jordan Fredj, Fondateur Hacksessible -
L'IA d'Hacksessible teste les race conditions, les manipulations de prix et les abus de coupons. Protegez votre chiffre d'affaires.