IOSOR

IOSOR Guides

Signature webhook et fenêtre de replay : l’idempotence pour que 02:00 soit ennuyeux

Vérifiez les signatures, bornez la fenêtre de replay et rendez les webhooks entrants idempotents — n’acceptez jamais de callbacks non signés, ne doublez jamais le débit prepaid sur un retry.

Un callback non signé n’est pas un événement. C’est du HTTP non authentifié qui ressemble par hasard à votre payload. Les équipes qui « acceptent d’abord, vérifient ensuite » paient à 02:00 : un DLR rejoué, un STOP dupliqué, ou un second débit de portefeuille que la finance ne peut pas défaire. Le prepaid rend l’échec visible en argent. Les habitudes ennuyeuses : vérifier la signature à chaque requête, une fenêtre de replay bornée, des clés d’idempotence que la finance lit à côté de la ligne de ledger.

IOSOR attend des intégrations B2B auditables : webhooks signés, secrets rotables, erreurs client-safe qui ne déversent pas de marques étrangères.

Les callbacks non signés ne sont pas des événements

Vérifiez la signature avant de parser les champs métier. Rejetez signatures manquantes, périmées ou décalées avec une erreur client-safe — ne traitez pas « quand même pour le pilote ». Un consommateur de staging qui saute la vérification entraîne la production à la sauter. Un catalogue live de messagerie ne signifie pas que votre URL webhook est une décharge publique.

Fenêtres de replay et pourquoi 02:00 arrive

La livraison au-moins-une-fois réessaie sur timeout, 5xx et perte réseau ambiguë. Un retry tardif à 02:00 est normal. La fenêtre borne combien de temps un payload signé reste acceptable : trop large et un attaquant rejoue un vieux STOP ; trop étroite et un retry légitime ressemble à une falsification. Journalisez les rejets de fenêtre à part des échecs de signature.

Idempotence que la finance peut lire

Le même ID d’événement doit produire le même état final. Extraire l’ID événement/message de la plateforme — n’inventez pas une clé avec horodatage plus corps. Renvoyez succès sur un ID connu sans redébiter. Les envois sortants ont besoin de la même discipline — idempotence, retries et argent.

Rotation de signature sans chaos de double acceptation

Faites tourner les secrets sans une fenêtre où anciennes et nouvelles signatures sont acceptées pour toujours. Planifiez le chevauchement, puis coupez. Ne collez jamais un secret de production dans un ticket. Séparez consommateurs sandbox et production. Dead-letter avec outillage de replay pour qu’ops puisse relancer un consommateur en échec sans inventer un second débit.

Signaux d’alerte

  • Le handler accepte des corps non signés « pour l’instant »
  • Pas de fenêtre de replay, ou une fenêtre mesurée en semaines
  • Écrasement de statut sans comparer les horodatages
  • Effets CRM/e-mail avant ACK
  • Secret de production dans le chat
  • ID d’événement dupliqués le mois dernier sans personne qui regarde
  • Erreurs client qui déversent des codes bruts d’amont

Commencez avec IOSOR

Ouvrez votre console IOSOR et examinez les paramètres de vos points de terminaison webhook actifs pour les accusés de réception entrants et les retours d évenements. Configurez une fenêtre de relecture stricte pour la vérification des signatures fixée à cinq minutes et liez votre gestionnaire exclusivement à l identifiant d évenement de la plateforme.

À retenir — IOSOR

L'absence de vérification des signatures et d'une fenêtre de relecture transforme les simples retries réseau en vulnérabilités critiques. Pour sécuriser vos flux, validez systématiquement l'horodatage UTC dans votre console et implémentez une idempotence stricte sur votre ledger. Cette rigueur garantit que les tentatives de livraison automatisées à 02:00 restent prévisibles, évitant ainsi toute modification d'état redondante ou export de données erroné.

Ce guide vous a-t-il aidé ?

Guides associés