Formater du JSON
Mettre en forme, valider et replier du JSON.
Développement
Signatures HMAC pour vérifier des webhooks.
Le cas d'usage quotidien, ce sont les webhooks.
Lorsqu'un service externe envoie une requête à votre serveur — une confirmation de paiement, un changement d'état — vous ne savez pas d'emblée si elle vient réellement de lui, car votre URL peut être connue de n'importe qui.
HMAC résout cela : l'émetteur calcule une signature à partir du contenu du message et d'un secret partagé, et l'envoie avec. Vous calculez la même signature avec le même secret et vous comparez.
Si elles correspondent, le message vient de quelqu'un qui connaît le secret et n'a pas été altéré.
Le second cas d'usage, ce sont les requêtes d'API signées, où la méthode, le chemin, un horodatage et le corps sont signés ensemble.
Une nuance importante : HMAC n'est pas du chiffrement. Le message reste lisible ; HMAC ne garantit que l'origine et l'intégrité.
Et ce n'est pas non plus une signature électronique au sens juridique : les deux parties connaissent le même secret, donc chacune peut produire la signature. Pour une valeur juridique en France, il faut les signatures électroniques au sens du règlement eIDAS, fondées sur de la cryptographie asymétrique et des certificats délivrés par un prestataire qualifié.
Les mêmes erreurs reviennent systématiquement à la vérification.
Comparez les signatures en temps constant. Une comparaison de chaînes ordinaire s'arrête au premier caractère différent, et de ce temps d'exécution on peut déduire la signature correcte progressivement. Presque tous les langages offrent une fonction dédiée.
Signez le corps brut de la requête, pas l'objet analysé puis resérialisé. Une différence d'espacement ou l'ordre des clés JSON change la signature.
Vérifiez l'horodatage si le fournisseur en envoie un, et rejetez les requêtes trop anciennes. Sinon, un attaquant peut rejouer plus tard un message valide.
Faites attention à l'encodage exact : hexadécimal ou Base64, majuscules ou minuscules, avec ou sans préfixe. Chaque fournisseur fait à sa manière, et c'est la cause la plus fréquente d'une signature qui « correspond presque ».
Et traitez le secret comme un mot de passe : ni dans le code, ni dans le dépôt, mais dans la configuration d'environnement.
Le choix est plus simple qu'il n'y paraît.
| Algorithme | Appréciation |
|---|---|
| HMAC-SHA256 | le choix standard |
| HMAC-SHA512 | également valable |
| HMAC-SHA1 | obsolète, systèmes anciens seulement |
| HMAC-MD5 | à ne pas utiliser |
SHA-256 est le choix par défaut raisonnable et celui qu'emploient la plupart des fournisseurs.
Fait notable : HMAC lui-même résiste plutôt bien aux faiblesses de la fonction de hachage sous-jacente, si bien que HMAC-SHA1 n'est pas considéré comme immédiatement cassé. Il n'y a pourtant aucune raison de le choisir pour du neuf.
La longueur de la clé devrait au moins égaler celle de la sortie de la fonction, soit 32 octets aléatoires avec SHA-256.
Et la clé doit être réellement aléatoire. Un secret inventé à la main est le maillon le plus faible de toute la chaîne.
Cet outil calcule entièrement dans votre navigateur et la clé ne quitte pas votre poste. Malgré tout : pour des secrets de production, utilisez votre propre environnement plutôt qu'une interface web.
À vérifier qu'un message — typiquement un webhook — est authentique et n'a pas été modifié.
Non. Le message reste lisible ; il garantit seulement l'origine et l'intégrité.
Parce que le temps d'une comparaison ordinaire permet de deviner la signature correcte.
Souvent parce que le corps a été resérialisé, ou à cause de l'encodage : hex contre Base64.
HMAC-SHA256 par défaut. Ne pas utiliser MD5.
Non, le calcul est local. Utilisez tout de même votre environnement pour la production.