Sujet : hmac
-
La spécification Standard Webhooks face à l'en-tête HMAC de Shopify et au jeton secret partagé de GitLab
La spécification Standard Webhooks définit les en-têtes webhook-id, webhook-timestamp et webhook-signature, un secret en base64 préfixé par whsec_ dont les octets décodés servent de clé HMAC, et une signature v1,<base64> calculée sur « {id}.{timestamp}.{payload} » ; les jetons de signature de GitLab (GitLab 19.0, disponibles en GA dans la 19.1) l'implémentent à l'identique. Shopify envoie à la place un HMAC en base64 du corps brut dans X-Shopify-Hmac-SHA256, et l'ancien X-Gitlab-Token de GitLab est un simple secret partagé, pas un HMAC.
-
Vérifier les signatures des requêtes Slack : X-Slack-Signature, fenêtre anti-rejeu de 5 minutes et règle des 3 secondes
Slack signe ses requêtes sous la forme v0=<HMAC-SHA256 en hexadécimal> de la chaîne "v0:{timestamp}:{corps brut}", dans l'en-tête X-Slack-Signature, accompagné de X-Slack-Request-Timestamp ; l'exemple de Slack rejette la requête si cet horodatage s'écarte de plus de cinq minutes de l'heure locale. Les commandes slash et les payloads interactifs doivent en outre être acquittés en moins de trois secondes, avant tout traitement long.
-
Vérifier les signatures des webhooks Stripe : Stripe-Signature, tolérance sur l'horodatage et rotation du secret
Stripe envoie un en-tête Stripe-Signature de la forme t=<timestamp>,v1=<hex signature>, calculé par HMAC-SHA256 sur la chaîne "{timestamp}.{raw body}" avec pour clé le secret d'endpoint whsec_ complet. Par défaut, les bibliothèques Stripe rejettent les signatures dont l'horodatage a plus de cinq minutes (300 secondes) et, tant qu'un ancien secret reste actif après une rotation (jusqu'à 24 heures), l'en-tête contient une valeur v1 par secret actif.
-
Vérifier les signatures des webhooks GitHub : X-Hub-Signature-256, comparaison à temps constant et identifiants de livraison
GitHub signe chaque livraison de webhook avec un HMAC-SHA256 calculé sur le corps brut de la requête et l'envoie sous la forme sha256=<hex digest> dans l'en-tête X-Hub-Signature-256. Le récepteur doit recalculer ce condensat à partir des octets exacts reçus, le comparer avec une fonction à temps constant et utiliser X-GitHub-Delivery pour reconnaître les événements relivrés ; l'ancien en-tête X-Hub-Signature (HMAC-SHA1) n'est conservé que pour la compatibilité.
-
Le piège du corps brut : pourquoi les parseurs JSON cassent la vérification des signatures de webhook
Les signatures de webhook basées sur HMAC sont calculées sur les octets exacts envoyés par le fournisseur ; tout middleware JSON qui analyse, réordonne ou resérialise le corps avant votre handler modifie ces octets et invalide la signature. Express, FastAPI, Flask, Django et Go exigent chacun une méthode précise pour capturer le corps intact avant le parsing normal, ou à sa place.
Lisible par machine : JSON