Générer et vérifier des signatures de webhook

Collez le corps brut et le secret pour générer ou vérifier une signature HMAC. Des formats GitHub et Stripe sont proposés ; la vérification ne contrôle pas l’ancienneté de l’horodatage ni le rejeu.

Fonctionne localement dans votre navigateur
Entrées de signature
Les sauts de ligne collés deviennent des LF dans ce champ. Activez cette option pour reproduire un corps signé avec des octets CRLF.
Signature générée
Enter a secret and payload to generate a signature.
Vérifier une signature reçue
Générez une signature ou collez une signature entrante pour la vérifier localement.
Aperçu de l'en-tête
Generate a signature to see the corresponding request header.
Modèles de vérification côté serveur
Generate a signature to see Node.js and PHP verification patterns.

Signez les octets exacts que vous avez reçus

Les vérifications des webhooks échouent lorsque le middleware analyse ou reformate le corps avant la vérification. Conservez le corps brut, appliquez l'entrée de signature documentée du fournisseur et utilisez une comparaison sécurisée dans le temps dans le code de votre serveur. Cette page n’envoie jamais la payload ou le secret nulle part.

Comment générer ou vérifier une signature de webhook

Signe le corps exact que vous collez avec HMAC-SHA-256, SHA-384 ou SHA-512, reproduit les formats X-Hub-Signature-256 de GitHub et v1 de Stripe, et compare une signature reçue octet par octet avec le même secret.

Le calcul se fait dans cet onglet via Web Crypto. Le corps, le secret et les signatures restent dans le navigateur ; une correspondance confirme les octets, pas l’ancienneté de l’événement.

  1. Choisissez le format : HMAC générique, GitHub X-Hub-Signature-256 ou Stripe v1. Les formats des fournisseurs utilisent toujours SHA-256.
  2. Collez le corps brut exact et le secret. Pour Stripe, cliquez sur Utiliser l’heure actuelle ou saisissez l’horodatage envoyé ; cochez Signer avec des fins de ligne CRLF si l’émetteur a signé des octets CRLF.
  3. Générez la signature pour voir l’en-tête correspondant et les exemples Node.js/PHP. Toute modification ultérieure estompe la valeur jusqu’à une nouvelle génération.
  4. Pour contrôler une valeur reçue, collez-la dans le champ de vérification puis cliquez sur Vérifier la signature. L’hexadécimal passe partout, le base64 passe pour les webhooks génériques, et un en-tête Stripe-Signature complet est lu avec son t=.
  5. Copier la signature reprend la valeur d’en-tête ; Effacer vide les champs et revient à HMAC générique.

Ce que contient le résultat généré

Entrée signée selon le format

Le HMAC générique signe le corps brut. GitHub signe ce même corps et envoie sha256=<hex> dans X-Hub-Signature-256. Stripe signe la chaîne <horodatage>.<corps> et envoie t=<horodatage>,v1=<hex> dans Stripe-Signature.

Quand un en-tête Stripe est collé, son t compose l’entrée signée ; le champ d’horodatage ne sert que si l’en-tête n’a pas de t=. Un secret en rotation peut produire plusieurs v1 ; la vérification passe si l’un d’eux correspond.

Pourquoi un corps identique peut échouer

La zone de texte transforme les CR et CRLF collés en LF. Si l’émetteur a signé des octets CRLF, cochez Signer avec des fins de ligne CRLF : chaque LF devient CRLF avant le calcul.

Toute différence de texte compte : JSON resérialisé, saut de ligne final supprimé, espace modifié, composant d’URL décodé ou corps déjà analysé donnent un autre condensat. Copier seulement la partie hexadécimale d’un en-tête supprime le préfixe sha256= ou v1= attendu, mais les deux formes sont acceptées.

Ce que la page ne vérifie pas

La vérification compare uniquement les octets HMAC. Elle ne rejette ni les horodatages anciens ni les événements rejoués, ne connaît pas la fenêtre de tolérance du fournisseur et ne contacte pas l’émetteur.

Le base64 est accepté pour les webhooks génériques ; GitHub et Stripe transmettent de l’hexadécimal, aucune vérification base64 ne leur est proposée. Révoquer un secret divulgué reste une tâche côté serveur.

Outils récents :