Quelle différence entre HMAC et hash ?

Un hash ne dépend que du contenu, donc n'importe qui peut le recalculer. Un HMAC dépend du contenu et d'une clé secrète, et seul celui qui a la clé produit la bonne signature. Le hash vérifie l'intégrité ; le HMAC vérifie l'intégrité et l'origine.

Pourquoi la signature du webhook ne correspond-elle pas ?

La plupart du temps, le corps a été modifié avant la vérification : JSON.parse suivi de JSON.stringify, un middleware qui l'a reformaté ou un saut de ligne en trop. Viennent ensuite un secret du mauvais environnement, une clé hex ou Base64 utilisée comme texte et un timestamp d'une autre requête. Collez ici le corps brut du log et comparez.

Faut-il retirer le sha256= de la signature ?

Pas ici : la page retire les préfixes comme sha256=, sha1= et v0= avant de comparer. Dans votre code, comparez la chaîne complète de l'en-tête avec "sha256=" + l'hex calculé, ou retirez d'abord le préfixe, comme le montre la documentation du fournisseur.

La signature est-elle en hex ou en Base64 ?

Cela dépend du fournisseur. GitHub, Stripe, Mercado Pago et Slack utilisent l'hex ; Shopify utilise le Base64. Les deux représentent les mêmes octets, et la page détecte le format à la longueur : 64 caractères hex ou 44 en Base64 pour SHA-256.

Quel algorithme utiliser pour HMAC ?

HMAC-SHA256, celui qu'utilisent les fournisseurs et le standard de fait. HMAC-SHA1 reste acceptable, car les faiblesses de SHA-1 ne concernent pas HMAC, mais on le voit surtout dans d'anciennes intégrations. Utilisez SHA-512 si la spécification le demande.

Le HS256 d'un JWT, c'est du HMAC ?

Oui. La signature d'un JWT HS256 est le HMAC-SHA256 de header.payload, écrit en base64url. Pour vérifier un token, utilisez le décodeur JWT, qui fait ce calcul avec votre secret.

Le secret whsec_ de Stripe est-il en Base64 ?

Pas pour Stripe : la bibliothèque officielle utilise toute la chaîne whsec_... comme clé texte. Laissez l'encodage de la clé sur Texte. D'autres services qui suivent la spécification Standard Webhooks utilisent aussi whsec_, mais décodent le Base64 qui suit le préfixe ; consultez la documentation de chacun.

Le payload et la clé sont-ils envoyés à un serveur ?

Non. Le HMAC est calculé par la Web Crypto API de votre navigateur, et rien de ce que vous collez n'est envoyé, enregistré ou placé dans l'URL. Les statistiques d'utilisation ne gardent que le modèle choisi, l'algorithme et si la signature correspondait.

Générateur HMAC et validateur de webhooks

Calculez un HMAC-SHA256, SHA-384, SHA-512 ou SHA-1 et vérifiez si la signature reçue avec le webhook correspond. Les modèles GitHub, Stripe, Shopify, Mercado Pago et Slack construisent le message signé comme le fait chaque fournisseur. Le payload et la clé restent dans votre navigateur.

Fournisseur

HMAC du payload tel quel, avec l'algorithme et l'encodage de votre choix.

Payload (corps brut)

La signature couvre le corps brut, octet par octet. Un espace, un saut de ligne ou un ordre des champs différent change déjà le résultat. Collez le corps exactement tel qu'il est arrivé, avant JSON.parse ou un formateur.

Clé secrète

La clé est en

Algorithme

Format de la signature

Signature reçue (facultatif)

Signature

Il manque la clé

Saisissez la clé secrète. La signature s'affiche pendant la saisie.

Un JWT HS256 est un HMAC-SHA256 du header et du payload. Le décodeur vérifie la signature du token avec votre secret.

Décoder un JWT

Vous voulez lire le payload du webhook ? Formatez-le dans un autre onglet. Le JSON formaté a d'autres octets et ne permet pas de vérifier la signature.

Formater le JSON

Besoin seulement d'un hash, sans clé ? Le générateur de hash calcule MD5, SHA-1 et SHA-256 de textes et de fichiers.

Générer un hash

Qu'est-ce que HMAC

HMAC est un hash calculé avec une clé secrète (RFC 2104). N'importe qui peut recalculer un simple SHA-256 après avoir modifié le message. Avec HMAC, seul celui qui connaît la clé peut produire la bonne signature. C'est pourquoi on l'utilise pour prouver qu'une requête vient bien de son émetteur et n'a pas été modifiée en route : webhooks, signature d'API comme AWS Signature V4 et tokens JWT HS256.

Format de chaque fournisseur

Chaque fournisseur choisit ce qu'il signe et comment il écrit le résultat. Le tableau résume les modèles de cette page ; chaque format a été vérifié dans la documentation officielle du fournisseur.

Fournisseur	En-tête	Ce qui est signé	Format
GitHub	X-Hub-Signature-256	corps	sha256=<hex>
Stripe	Stripe-Signature	t.corps	t=<ts>,v1=<hex>
Shopify	X-Shopify-Hmac-Sha256	corps	<base64>
Mercado Pago	x-signature	id:…;request-id:…;ts:…;	ts=<ts>,v1=<hex>
Slack	X-Slack-Signature	v0:timestamp:corps	v0=<hex>

Comment fonctionne la vérification d'un webhook

Le fournisseur et votre application partagent le même secret. En envoyant l'événement, le fournisseur calcule le HMAC du corps, ou d'un message construit avec un timestamp et le corps, et envoie le résultat dans un en-tête. Votre application le recalcule avec le corps reçu et compare. Si cela correspond, l'événement est authentique. La comparaison doit se faire en temps constant, avec crypto.timingSafeEqual en Node, hash_equals en PHP ou hmac.compare_digest en Python, pour ne pas laisser fuir la signature par le temps de réponse.

La première cause de signature invalide

Le framework transforme le JSON en objet avant votre code, et en le sérialisant à nouveau, l'ordre des clés, les espaces et l'échappement des accents changent. La signature ne correspond plus, même avec la bonne clé. Lisez le corps brut : express.raw() dans Express, $request->getContent() dans Laravel, un paramètre String avec @RequestBody dans Spring et request.get_data() dans Flask. Dans NestJS, créez l'application avec rawBody: true et utilisez req.rawBody.

Clé en texte, hex ou Base64

HMAC travaille sur les octets de la clé. Si le tableau de bord du fournisseur affiche un secret en hex et que vous utilisez cette chaîne comme texte, les octets diffèrent et la signature aussi. La plupart des fournisseurs de webhooks, dont GitHub, Stripe, Shopify, Mercado Pago et Slack, utilisent le secret comme texte, tel qu'il apparaît dans le tableau de bord, préfixe whsec_ de Stripe compris.

Timestamp et rejeu

Une requête valide interceptée reste valide si elle est renvoyée. Stripe et Slack placent le timestamp dans le message signé, et leurs bibliothèques refusent les événements de plus de 5 minutes. En testant avec un ancien payload copié depuis un log, la signature peut correspondre ici et être quand même refusée par votre serveur à cause de l'heure.

Questions fréquentes sur HMAC

Signature de webhooks, clé, encodage et les erreurs de validation les plus courantes.