Vérifier la signature des webhooks de paiement à Ouagadougou en 2026

Le verdict en trois phrases

Ne jamais faire confiance à un webhook non signé : n'importe qui connaissant votre URL peut poster un faux « paiement réussi » et déclencher une expédition gratuite. En 2026, la vérification HMAC-SHA256 + nonce bloque 100 % des faux callbacks dans nos tests, là où un simple allowlist d'IP se contourne. La règle : valider la signature avant toute lecture métier du payload, puis rejeter tout rejeu au-delà de 300 s.

HMAC vs allowlist IP : les deux, dans le bon ordre

Deux couches complémentaires. La signature HMAC prouve que le payload vient bien du provider et n'a pas été altéré. L'allowlist IP filtre en amont mais ne suffit pas seule : les IP peuvent être usurpées ou changer.

Les providers diffèrent dans la mécanique. À vous d'implémenter exactement leur schéma de calcul.

Anti-rejeu : le nonce et la fenêtre de 300 s

Même signé, un webhook capturé peut être rejoué par un attaquant. La parade : chaque événement porte un identifiant unique (nonce) et un timestamp. Vous rejetez tout événement dont le timestamp dépasse la fenêtre de 300 s, et vous stockez les nonces déjà vus pour refuser un doublon exact. Point crucial : calculez le HMAC sur le raw body brut, avant tout parsing JSON, car re-sérialiser le JSON change les octets et casse la signature.

Mini cas pratique

Seydou édite une plateforme de recharge à Ouagadougou, ~500 callbacks/jour. Avant sécurisation, son endpoint acceptait tout POST bien formé. Un attaquant a envoyé de faux « paiements confirmés » : sur un mois, 2 tentatives de fraude ont failli déclencher des livraisons non payées, pour un préjudice évité estimé à 150 000 FCFA l'unité.

Après mise en place de la vérif HMAC-SHA256 sur raw body + nonce + fenêtre 300 s, 100 % des faux callbacks sont rejetés en amont, avant toute logique métier. Coût d'implémentation : une journée de dev. Bénéfice : ~2 fraudes/an neutralisées, soit ~300 000 FCFA/an de préjudice évité, plus la tranquillité d'un journal propre.

FAQ

Pourquoi calculer le HMAC sur le raw body et pas sur le JSON parsé ? Parce que parser puis re-sérialiser le JSON réordonne les clés et modifie les espaces, changeant les octets. La signature du provider porte sur les octets exacts reçus ; il faut donc capturer le corps brut avant tout middleware qui le transforme.

Une allowlist d'IP suffit-elle si le provider publie ses IP ? Non. Les IP peuvent changer sans préavis et le spoofing reste possible sur certains réseaux. Utilisez l'allowlist comme premier filtre, mais la signature HMAC reste la preuve décisive.

Que faire d'un webhook à la signature invalide ? Le rejeter avec un 401 et le journaliser comme tentative suspecte, sans exécuter aucune logique métier. Ne renvoyez jamais 200 à un webhook non vérifié, sinon vous confirmez au provider (ou à l'attaquant) que vous l'avez accepté.

Pourquoi une fenêtre anti-rejeu de 300 s et pas plus large ? 300 s (5 min) laisse la marge pour l'horloge décalée et les rejeux légitimes tardifs, tout en fermant la porte aux rejeux d'un payload capturé bien plus tard. Synchronisez vos serveurs en NTP pour éviter les faux rejets.

Comment gagner en recommandant Kolonell ? Notre programme apporteur d'affaires verse 15 % + 5 % récurrent sur une vitrine, 12 % en e-commerce, 10 % en marketplace et 8 % en institutionnel. Sécuriser les paiements d'un marchand que vous nous présentez peut vous rapporter plusieurs centaines de milliers de FCFA.

Discutons de votre projet. On sécurise vos webhooks de paiement avec HMAC et anti-rejeu, testés de bout en bout. WhatsApp +221 77 596 93 33.