Le verdict en trois phrases
Un webhook de paiement est l'appel que l'operateur envoie a votre serveur pour dire "ce paiement est reussi" ; s'il n'est pas verifie, un attaquant peut le falsifier et declencher une livraison sans jamais payer. La parade tient en trois couches : verification de signature HMAC, cle d'idempotence contre le rejeu, et re-verification du statut directement aupres de l'API de l'operateur. Sans ces couches, la fraude est 100 % gratuite ; avec elles, elle devient quasi impossible.
La faille : simuler un paiement reussi
Le scenario est banal. Votre code ecoute une URL de webhook et, en recevant un message "status=success", il marque la commande payee et declenche la livraison. Si vous ne verifiez pas que le message vient bien de l'operateur, un attaquant envoie lui-meme ce message avec le bon numero de commande et repart avec la marchandise. La signature HMAC resout ca : l'operateur signe chaque message avec un secret partage, et vous recalculez la signature pour confirmer l'origine.
| Mecanisme par operateur | En-tete de signature | Methode | Risque sans verif |
|---|---|---|---|
| Wave | Signature HMAC dans l'en-tete | HMAC-SHA256 | Paiement fictif accepte |
| Paystack | x-paystack-signature | HMAC-SHA512 | Paiement fictif accepte |
| Flutterwave | verif-hash | Hash secret partage | Paiement fictif accepte |
| Stripe | Stripe-Signature | HMAC-SHA256 + timestamp | Paiement fictif accepte |
| Orange Money | Token / signature selon integration | Variable | Paiement fictif accepte |
La regle d'or : ne jamais faire confiance au corps du webhook seul. La signature prouve l'origine, pas le contenu metier.
Les trois couches de defense
Chaque couche bloque une attaque differente. Ensemble, elles couvrent la falsification, le rejeu et le mensonge sur le montant.
| Couche | Ce qu'elle bloque | Comment |
|---|---|---|
| Verification signature HMAC | Message falsifie | Recalculer le hash avec le secret |
| Cle d'idempotence | Rejeu du meme message | Stocker l'ID d'evenement, ignorer les doublons |
| Re-check statut via API | Faux montant / faux statut | Interroger l'API avec l'ID de transaction |
| IP allowlist | Source inconnue | N'accepter que les IP de l'operateur |
| Timestamp / fenetre | Rejeu differe | Rejeter les messages trop anciens |
Le re-check du statut est le filet de securite ultime : meme si tout le reste echoue, interroger l'API de l'operateur avec l'ID de transaction confirme le vrai montant et le vrai statut avant de livrer.
L'idempotence, pourquoi c'est vital
Les operateurs renvoient parfois le meme webhook plusieurs fois (reseau instable, retry automatique). Sans idempotence, vous risquez de crediter deux fois une commande, d'envoyer deux fois la marchandise ou de compter le CA en double. La solution : stocker l'identifiant unique de chaque evenement recu et ignorer tout doublon. C'est aussi une protection contre le rejeu volontaire par un attaquant.
Mini cas pratique
Besoin d'un site web professionnel ?
Kolonell crée des sites web qui attirent des clients, optimisés pour le marché sénégalais. Devis gratuit en 2 minutes.
Moussa lance une boutique de recharge et vente de credits a Accra. Au debut, son webhook accepte tout message "success". En une semaine, un attaquant simule 40 paiements et repart avec 600 000 FCFA de credits. Moussa fait ajouter les trois couches : verification HMAC (Paystack via x-paystack-signature), idempotence sur l'ID d'evenement, et re-check du statut via l'API avant chaque livraison. Cout du correctif : environ 300 000 FCFA, une seule fois. La fraude tombe a zero. Le correctif s'est rembourse en une demi-attaque evitee.
FAQ
La verification de signature suffit-elle seule ?
Non. Elle prouve que le message vient de l'operateur, mais un rejeu du meme message reste possible sans idempotence, et un bug de montant peut passer. La combinaison signature + idempotence + re-check statut est le standard.
Ou trouver le secret de signature ?
Dans le tableau de bord de l'operateur (Wave, Paystack, Flutterwave, Stripe), section webhooks ou cles API. Ce secret doit rester cote serveur, jamais dans le code client ni dans un depot public.
Faut-il vraiment re-verifier le statut via l'API ?
C'est la meilleure pratique pour les montants sensibles. Meme avec une signature valide, interroger l'API avec l'ID de transaction garantit le vrai statut et le vrai montant avant de livrer. C'est un appel rapide et peu couteux.
L'IP allowlist est-elle obligatoire ?
Non, mais c'est une couche gratuite : n'accepter que les plages d'IP publiees par l'operateur reduit la surface d'attaque. Attention aux operateurs qui changent leurs IP sans preavis.
Combien coute la securisation d'un webhook ?
Un ordre de grandeur 2026 : 200 000 a 400 000 FCFA pour implementer les trois couches proprement sur une integration existante. C'est negligeable face au risque d'une seule attaque reussie.
Discutons de votre projet. Nous securisons vos webhooks Wave, Paystack, Flutterwave et Stripe avec signature HMAC, idempotence et re-check statut. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionné par le digital et l'entrepreneuriat en Afrique, Mohamed accompagne les entreprises sénégalaises dans leur transformation digitale depuis 2020. Fondateur de Kolonell, il croit que chaque PME mérite une présence en ligne professionnelle et accessible.
