Sécurité des webhooks de paiement : tester les rejouements et les événements en double

La décision que ce guide vous aide à prendre

Vérifiez à la fois qui a envoyé l’événement et ce que le destinataire en fait. Définissez les attentes concernant l’identité et l’ordre des événements, puis testez des événements synthétiques répétés et reçus dans le désordre. Confirmez l’état du paiement qui en résulte, au lieu de considérer qu’une vérification de signature réussie constitue une protection complète.

Commencez par le contrat d’intégration

Consignez la manière dont l’émetteur authentifie un événement, dont les horodatages sont traités et dont le destinataire identifie les doublons. Confirmez l’environnement et le matériel de signature utilisés pour le test. Le comportement propre à un fournisseur doit être défini à partir de sa documentation et des modalités convenues pour l’environnement de test isolé.

Tester les événements répétés et reçus hors séquence

Un événement authentique peut arriver deux fois ou après une modification ultérieure de l’état. Utilisez un petit ensemble d’événements convenu pour observer l’idempotence et la gestion des transitions d’état. Consignez si l’application répète un effet secondaire, ignore une mise à jour valide ou applique une opération à la mauvaise version de la transaction.

Distinguer la sécurité des hypothèses de réalisation

Une nouvelle tentative de livraison ne constitue pas nécessairement une attaque, et l’ordre du réseau n’est pas une règle métier fiable. Le destinataire doit valider l’authenticité de l’événement et déterminer si la transition demandée est autorisée dans l’état actuel. Consignez l’état obtenu et l’entrée d’audit, et pas uniquement l’accusé de réception HTTP.

Délimiter les tests

Utilisez des transactions synthétiques, un règlement désactivé et des limites de concurrence explicites. Sans autorisation, n’envoyez pas d’événements de test à l’infrastructure de production des commerçants d’un prestataire. Transformez chaque défaut confirmé en un cas de régression couvrant à la fois la réutilisation malveillante et les nouvelles tentatives légitimes du prestataire.

Consigner par écrit le contrat d’événements

Définissez la conduite à tenir par le destinataire face à un nouvel événement, à une livraison répétée, à un événement tardif et à un événement contradictoire avec l’état actuel de la transaction. Utilisez les identifiants d’événement et les règles de nouvelle tentative réellement appliqués par le fournisseur. Certains systèmes effectuent intentionnellement plusieurs livraisons ; rejeter toute répétition n’est donc pas nécessairement le bon comportement. La question essentielle est de savoir si une répétition entraîne un effet métier supplémentaire non prévu ou empêche une voie de reprise légitime.

Convenir du contrat avec les responsables du produit et de l’intégration avant les tests. Consigner la manière dont l’authenticité, la fraîcheur, l’identité de l’événement et l’état de la transaction contribuent à la décision. Ces contrôles répondent à des problèmes différents et ne doivent pas être considérés comme interchangeables.

Observer les effets à l’aide d’un ensemble contrôlé d’événements

Préparez une courte séquence autour d’une transaction synthétique. Établissez le traitement normal, renvoyez l’événement convenu et introduisez une variation d’ordre autorisée. Consignez l’accusé de réception, le résultat de la file d’attente ou du processus worker, ainsi que l’état final de l’activité. Ne générez aucun flux de paiement vers un prestataire externe sans son autorisation et n’utilisez pas un règlement réel comme preuve. Si le destinataire dispose d’un environnement de test, confirmez quelles propriétés de production il représente et lesquelles il ne représente pas.

Le guide des tests d’intrusion sur l’autorisation des paiements bancaires explique pourquoi l’état enregistré d’une transaction compte davantage qu’un message de réussite. N’incluez des observations sur le rapprochement ou le grand livre que si elles relèvent explicitement du périmètre de test autorisé.

Recommander un invariant de traitement précis

Une recommandation utile décrit l’invariant métier visé : par exemple, retraiter le même événement synthétique reconnu ne doit pas créer un second crédit pour la même transaction. La mise en œuvre peut faire appel à des enregistrements d’événements, à des transitions d’état atomiques ou à d’autres contrôles propres au produit. Évitez de prescrire un cache de déduplication simpliste sans comprendre les délais d’expiration, les nouvelles tentatives et les versions légitimes des événements. Une correction doit permettre au service de se rétablir après une interruption de livraison.

Retestez les cas normaux, répétés et désordonnés sur la version modifiée. Les intégrations cliniques ont des sémantiques différentes, mais le guide de test des intégrations hospitalières illustre la même rigueur en matière de preuves : l’accusé de réception, le routage et l’état final du processus doivent être décrits séparément. Respectez les limites de la comparaison sans considérer tous les systèmes fondés sur des messages comme identiques.

Mettez les recommandations en pratique

Utilisez la liste de préparation pour consigner les hypothèses, ou consultez le rapport fictif de Fintech AG pour des exemples d’éléments probants et de plans de traitement. Contactez Atlant Security en fournissant une description non sensible du périmètre.