# HMAC-SHA256 pour la signature des webhooks DLR — comment et pourquoi

> HMAC-SHA256 est l'algorithme cryptographique utilisé par toutes les plateformes de messagerie modernes pour signer les accusés de réception et les webhooks de messages entrants. La plateforme calcule un hachage chiffré du corps de la requête à l'aide d'un secret partagé ; votre point de terminaison recalcule ce même hachage et le compare. Cela prouve que le webhook provient bien de la plateforme — et non d'une personne ayant deviné votre URL — et que le corps de la requête n'a pas été altéré lors de sa transmission.

- URL canonique: https://www.broadnet.me/fr/answers/hmac-sha256-dlr-signing
- Langue: fr
- Dernière révision: 2026-09-24
- Éditeur: BroadNet (https://www.broadnet.me)

## Comment la signature est construite

Une construction courante forme la chaîne canonique `${timestamp}.${requestBody}`, calcule `HMAC-SHA256(canonical, secret)`, l'encode en hexadécimal et envoie l'empreinte et l'horodatage dans un en-tête de signature. Inclure l'horodatage dans la charge signée empêche les attaques par rejeu : votre point de terminaison doit rejeter les webhooks de plus de 5 minutes. Les noms d'en-têtes et le format canonique exact varient d'une plateforme à l'autre ; confirmez-les auprès de votre fournisseur avant d'écrire le code de vérification.

## Pourquoi les signatures HMAC et non RSA ?

HMAC est symétrique (les deux parties partagent un secret), ce qui signifie que la signature et la vérification sont environ 10 000 fois plus rapides qu'avec RSA-2048. Dans le cas d'une diffusion massive de webhooks où un seul SMSC peut émettre jusqu'à 50 000 DLR par seconde, la signature RSA monopolise le processeur. Sur du matériel moderne, HMAC-SHA256 s'exécute en quelques microsecondes. En contrepartie, quiconque détient le secret peut signer ; le secret ne doit donc être partagé qu'entre la plateforme et votre environnement, stocké comme n'importe quel identifiant et pouvoir être renouvelé à la demande.

## Pièges de la vérification

Trois bogues courants : comparer des chaînes avec `==` au lieu d'une comparaison en temps constant (attaque temporelle — utilisez `crypto.timingSafeEqual`) ; valider la signature après l'analyse JSON du corps (vous devez vérifier les octets bruts, et non une représentation resérialisée — le réordonnancement JSON invalide le hachage) ; oublier la fenêtre anti-rejeu de l'horodatage.

## Au-delà de HMAC

Pour les environnements réglementés (banques, santé), certaines plateformes prennent aussi en charge la livraison des webhooks en mTLS : l'expéditeur présente un certificat client que votre répartiteur de charge valide avant que la requête n'atteigne l'application. C'est plus robuste que HMAC, car la livraison est liée à une clé matérielle, mais cela ne se justifie que pour des charges réellement sensibles. Pour la plupart des intégrations, HMAC-SHA256 sur HTTPS est la bonne réponse.

## Voir aussi

- [Toutes les réponses](https://www.broadnet.me/fr/answers)
- [Glossaire](https://www.broadnet.me/fr/answers)
- [TLS 1.3 dans la messagerie — ce qui a changé et pourquoi c'est important pour SMPP](https://www.broadnet.me/fr/answers/tls-1-3-in-messaging)
- [Qu'est-ce qu'un DLR (Delivery Receipt) ?](https://www.broadnet.me/fr/answers/what-is-dlr)
- [Webhook setup](https://www.broadnet.me/fr/developers/webhooks)