Webhook reçu : vérifier sa signature avant d’automatiser

Votre logiciel reçoit un message annonçant qu’un document est prêt. L’automatisation doit créer une tâche pour l’équipe. Mais avant de lancer ce travail, comment sait-elle que le message vient réellement du service attendu ? Le nom de ce service dans les données reçues ne suffit pas.

Un webhook est une notification qu’une application transmet à une adresse de votre système. Cette adresse constitue un point d’entrée : il faut contrôler ce qui arrive avant d’autoriser une action. Voici une méthode de cadrage pour une PME et son intégrateur. Le parcours proposé est fictif ; il ne décrit pas un incident client.

Identifier ce que la notification peut déclencher

Commencez par une fiche simple : service émetteur, compte concerné, événements utiles et actions autorisées. Dans notre exemple, une notification « document disponible » prépare une tâche interne. Elle ne doit ni changer le propriétaire du dossier ni envoyer le document à une adresse ajoutée dans un commentaire.

Ajoutez deux questions : où la notification est-elle contrôlée et quelle étape peut modifier vos données ? Demandez à voir le chemin complet, y compris un éventuel relais entre le service et votre outil d’automatisation.

Cette fiche permet de séparer trois décisions : reconnaître l’émetteur, accepter l’événement et autoriser l’action métier. Réussir la première ne dispense pas des deux autres.

Vérifier la signature, pas seulement sa présence

Certains services accompagnent chaque notification d’une signature calculée à partir du message et d’un secret partagé. Le serveur destinataire vérifie cette signature selon la procédure du fournisseur. Le secret doit rester protégé : une signature ne permet plus de distinguer l’émetteur légitime d’un tiers qui dispose du même secret.

GitHub documente par exemple une signature HMAC-SHA256 transmise dans l’en-tête X-Hub-Signature-256. Il demande de la vérifier avant le traitement, avec une comparaison adaptée pour limiter les attaques liées au temps de calcul. Lire cet en-tête sans vérifier sa valeur ne réalise aucun contrôle. Source : validation des webhooks GitHub.

Pour votre projet, demandez la méthode exacte du service utilisé. Un connecteur qui reçoit les notifications n’assure pas nécessairement cette vérification. Si elle est déjà effectuée par un composant intermédiaire, faites préciser comment celui-ci transmet le résultat et empêche un accès direct non vérifié au workflow.

Ne remplacez pas ce contrôle par une consigne à une IA. Le jugement « ce message semble authentique » n’est pas une validation cryptographique.

Conserver le message original jusqu’au contrôle

Une transformation apparemment anodine peut casser la vérification. Stripe exige le corps brut de la requête : une modification avant validation fait échouer la signature. Il recommande ses bibliothèques officielles, auxquelles on fournit le message, l’en-tête Stripe-Signature et le secret du point de réception. Source : réception des événements Stripe.

La question pratique à poser est donc : « À quel moment le message est-il transformé ? » Pour ce type de mécanisme, placez le contrôle avant les étapes qui réécrivent les données. Vérifiez aussi le comportement du relais ou du framework utilisé par le développeur.

En cas d’échec, arrêtez les actions métier. Ne désactivez pas la vérification pour rétablir rapidement le flux. Faites rechercher la cause : mauvais secret, configuration incorrecte ou message modifié en chemin. GitHub recommande également de conserver le contenu et les en-têtes sans modification avant validation. Source : diagnostic GitHub.

Distinguer authenticité, fraîcheur et droit d’agir

Une ancienne notification authentique peut être retransmise. Stripe inclut un horodatage dans les éléments signés et permet de rejeter une livraison trop ancienne. Ses bibliothèques appliquent par défaut une tolérance de cinq minutes ; cette valeur est propre à ce mécanisme, pas une règle universelle. Source : protection Stripe contre le rejeu.

La fraîcheur ne remplace pas la gestion des doublons. Pour cette seconde protection et les reprises après incident, notre guide sur les doublons d’automatisation détaille les points à vérifier.

Une fois l’origine contrôlée, limitez les événements acceptés et vérifiez leur type avant traitement. GitHub recommande explicitement de contrôler le type d’événement et son action. Source : bonnes pratiques GitHub.

Dans notre scénario, vérifiez ensuite que le document appartient au dossier attendu et que la création d’une tâche reste pertinente. Un commentaire rédigé par un tiers demeure un contenu à lire, même lorsqu’il est transporté par une notification correctement signée. Il ne doit pas élargir les permissions de votre automatisation.

Demander une démonstration avec des messages refusés

Un essai réussi ne montre pas que les contrôles fonctionnent. Dans un environnement isolé, sans envoi client ni modification de production, préparez cette recette avec des données fictives :

• Un message valide et attendu : la tâche autorisée est créée.
• Une signature absente ou incorrecte : aucune action métier ne démarre.
• Un contenu modifié après signature : la vérification échoue.
• Un événement authentique hors périmètre : aucune action non prévue n’est exécutée.
• Une livraison ancienne : le comportement respecte la protection documentée du fournisseur.
• Un secret de test remplacé : le flux fonctionne avec la configuration attendue et refuse l’ancien secret une fois sa période d’acceptation terminée.

Pour chaque essai, conservez le résultat attendu, le résultat observé et une preuve des actions réellement exécutées. Un écran affichant « erreur » ne suffit pas si une tâche a déjà été créée avant le contrôle.

Prévoir l’exploitation sans exposer les secrets

Désignez la personne qui traite les échecs de validation. Nous recommandons un journal limité : date, point de réception, catégorie d’erreur et repère technique utile à l’enquête. Évitez d’y recopier le secret ou l’intégralité des documents clients.

GitHub déconseille les identifiants sensibles dans l’URL du webhook et recommande HTTPS avec vérification du certificat. Ces mesures complètent la signature ; elles ne la remplacent pas. Source : sécurisation des webhooks GitHub.

Avant la mise en service, demandez une fiche de réception, une preuve des tests négatifs et une procédure de remplacement du secret. Si le fournisseur ne propose pas de signature, faites documenter son mécanisme d’authentification réel et ses limites avant de lui confier des actions importantes. Ne présentez pas une simple adresse difficile à deviner comme une protection équivalente.

Sources

Documentation officielle consultée le 25 octobre 2026. Les mécanismes diffèrent selon les fournisseurs et les connecteurs ; ce guide propose des contrôles de conception, pas une certification de sécurité.

• GitHub : valider les notifications webhook.
• Stripe : recevoir et vérifier les événements.
• GitHub : bonnes pratiques pour les webhooks.