Sécurité e-commerce : failles exploitées sur paiement, comptes clients et back-office
Un e-commerce n’est pas qu’un site web. C’est un ensemble de flux à forte valeur : comptes clients, paiements, promotions, remboursements, logistique, support, et back-office. Les attaques qui réussissent ne reposent pas toujours sur une vulnérabilité “spectaculaire”. Elles exploitent souvent des failles de logique, des contrôles d’autorisation incomplets, ou une intégration tiers mal cadrée.
L’objectif de cet article est double : vous aider à reconnaître les scénarios les plus exploités, et vous donner une checklist de contrôles concrets à vérifier avant d’investir dans un pentest e-commerce.
Paiement : ce qui casse en premier
Le paiement est souvent externalisé (PSP) mais votre application garde une responsabilité centrale : créer l’intention de paiement, calculer le montant, appliquer les remises, et valider le résultat.
Manipulation de montant et de panier
Scénario courant :
- le client modifie le payload du panier (prix unitaire, quantité, remise)
- l’application fait confiance au client au lieu de recalculer côté serveur
- le PSP encaisse un montant inférieur, mais la commande est validée
Contrôles à vérifier :
- recalcul serveur systématique (prix, taxes, shipping, coupons)
- signature serveur des éléments de panier (ou stockage serveur)
- refus explicite si divergence entre “commande” et “paiement”
Coupons et promotions : la logique est une surface d’attaque
Problèmes fréquents :
- cumul de remises non prévu
- utilisation multiple de coupons “unique”
- application de coupons sur produits exclus
- bypass de règles (nouveau client, minimum d’achat)
Contrôles :
- règles de promotion testées comme du code (tests unitaires/integ)
- validation serveur unique source of truth
- logs d’usage des coupons et alertes sur anomalies
Webhooks : l’endroit où l’on “termine” le paiement
Le webhook est un endpoint critique : il valide le paiement et déclenche la suite (commande, facture, activation).
Erreurs fréquentes :
- absence de vérification de signature
- endpoint accessible sans contrôle (spoof de paiement)
- idempotence absente (double exécution)
Contrôles :
- vérification stricte des signatures (PSP)
- idempotence : un événement ne s’applique qu’une fois
- corrélation : paiement -> commande -> statut attendu
- accès réseau contrôlé si possible (allowlist)
Comptes clients : prise de contrôle et fraude
Reset password et récupération de compte
Les mécanismes de récupération sont souvent le maillon faible :
- tokens trop longs, non invalidés, ou réutilisables
- liens envoyés à des emails non vérifiés
- erreurs de messages facilitant l’énumération d’utilisateurs
Contrôles :
- TTL court, invalidation après usage
- limitation de fréquence (par IP et par compte)
- pas d’énumération via messages d’erreur
Sessions : persistance et contournements
Dans un e-commerce, les sessions couvrent :
- panier
- adresses et moyens de paiement
- historique de commandes
- remboursements et SAV
Contrôles :
- cookies Secure/HttpOnly/SameSite cohérents
- rotation après login
- invalidation à la déconnexion
- actions sensibles avec step-up auth (selon risque)
Autorisation : l’IDOR est fréquent
Scénario :
- un client accède à la commande d’un autre en changeant un ID
- un endpoint d’export ou de facture ne vérifie pas l’appartenance
Contrôles :
- vérification côté serveur de l’appartenance sur chaque ressource
- UUID ou IDs non prévisibles ne suffisent pas : il faut un contrôle d’accès
Back-office : le vrai multiplicateur de risque
Le back-office concentre les actions à fort impact :
- modification de prix
- création de coupons
- remboursements
- changements de statut commande
- gestion des stocks
RBAC incomplet et permissions trop larges
Erreurs fréquentes :
- un rôle “support” peut déclencher des remboursements
- permissions gérées dans l’UI mais pas côté API
- endpoints admin partagés avec endpoints client
Contrôles :
- matrice de permissions écrite (rôle -> actions)
- tests d’autorisation sur chaque endpoint sensible
- journalisation des actions admin (qui, quoi, quand)
CSRF et actions sensibles
Si votre back-office utilise des cookies, le CSRF redevient pertinent.
Contrôles :
- protections CSRF pour les actions mutatives
- confirmation supplémentaire pour actions irréversibles
- scopes de session admin séparés
Imports/exports : un risque sous-estimé
Points à vérifier :
- validation stricte des fichiers importés
- limitation de taille et quotas
- sanitation des exports (CSV injection)
- contrôles d’accès sur les exports
Checklist “pentest e-commerce” (prête à utiliser)
Paiement
- recalcul serveur des montants
- validation stricte des webhooks (signature, idempotence)
- gestion des erreurs de paiement (pas de “commande payée” par défaut)
- tests sur coupons et promotions
Comptes clients
- protections brute force
- reset password robuste
- sessions sécurisées
- IDOR sur commandes, factures, adresses
Back-office
- RBAC/permissions vérifiées côté serveur
- logs d’actions admin
- CSRF si cookies
- imports/exports sécurisés
Liens internes utiles
Pour cadrer un test adapté :
- Pentest application web : https://obveron.com/pentest-application-web
- Pentest (général) : https://obveron.com/pentest
- Audit de sécurité web : https://obveron.com/audit-securite
- Échange 15 minutes : https://obveron.com/book-a-call
Pour des références officielles (limitées à l’essentiel) :
- OWASP Testing Guide : https://owasp.org/www-project-web-security-testing-guide/
- OWASP ASVS (exigences) : https://owasp.org/www-project-application-security-verification-standard/
Conclusion
Sur un e-commerce, la sécurité se joue sur les détails : recalcul serveur, autorisation, webhooks, et back-office. Un pentest utile doit tester des scénarios proches du réel, prioriser selon l’impact business, et livrer des recommandations actionnables.
Si vous voulez cadrer rapidement un pentest e-commerce (paiement, comptes, back-office), vous pouvez réserver un échange : https://obveron.com/book-a-call