Webhook : HTTP callback
Réseau
Mécanisme par lequel une application en prévient une autre en envoyant une requête HTTP (le plus souvent un POST avec un corps JSON) vers une URL convenue, dès qu'un événement se produit. Le rapport s'inverse : on ne demande plus « alors, du nouveau ? », on est appelé.
Principe : Le récepteur expose un point d'entrée HTTP et l'enregistre auprès du service émetteur, avec la liste des événements qui l'intéressent. À chaque événement (paiement validé, push sur un dépôt, ticket fermé), l'émetteur envoie une requête avec la charge utile, ce qui évite d'interroger une API en boucle pour rien.
Authenticité : L'URL est publique, donc n'importe qui peut y poster. L'émetteur signe en général le corps avec un secret partagé (HMAC dans un en-tête) et ajoute un horodatage : on recalcule la signature, on la compare en temps constant et on rejette les messages trop anciens pour bloquer le rejeu.
Livraison et doublons : La plupart des émetteurs garantissent une livraison « au moins une fois » et relancent tant qu'ils ne reçoivent pas de 2xx. Le traitement doit donc être idempotent, en s'appuyant sur l'identifiant d'événement. Vingt ans de métier apprennent que le webhook reçu deux fois finit toujours par débiter deux fois, alors que l'identifiant d'événement était là, dans l'en-tête, depuis le début.
Répondre vite : L'émetteur applique un délai d'expiration court. On vérifie la signature, on dépose l'événement dans une file, on renvoie 2xx tout de suite et on traite en asynchrone.
Ce qui arrive si on s'en passe
Sans webhook, l'application qui attend un événement doit interroger l'autre à intervalles réguliers. Tout ce qui survient entre deux interrogations reste invisible jusqu'au passage suivant : une alerte, une révocation d'accès ou un paiement refusé n'est traité qu'avec ce retard, et pendant ce délai l'état connu localement est faux. Si l'API interrogée ne renvoie que l'état courant, les changements intermédiaires (un statut modifié puis rétabli, par exemple) ne sont jamais observés et ne laissent aucune trace côté consommateur. Raccourcir l'intervalle multiplie les requêtes inutiles, consomme les quotas et peut déclencher une limitation de débit qui retarde encore la détection. L'absence de webhook n'ouvre pas de faille en soi ; elle allonge la fenêtre pendant laquelle un événement important reste sans réaction.
Explication de la marmotte
Imagine que tu attends un colis. Tu pourrais aller vérifier ta boîte aux lettres toutes les cinq minutes : c'est fatigant, et la plupart du temps elle est vide. Ou bien tu donnes ton numéro au livreur, et il t'envoie un message dès que le colis arrive. C'est ça, l'idée : un site ou une application prévient automatiquement un autre programme au moment où quelque chose se passe (un paiement accepté, une commande passée), au lieu d'attendre qu'on vienne lui demander. Pour éviter les farceurs, le message porte une sorte de cachet secret que seuls les deux programmes connaissent, ce qui permet de vérifier qu'il vient bien du bon expéditeur.
Où ce terme est utilisé
- Comment bloquer un webhook forgé sans signature vérifiée (11 occurrences)
- Comment sécuriser les webhooks entrants (9 occurrences)
- Attaques par canaux auxiliaires et secrets (2 occurrences)
- CICD-SEC-8 : usage non gouverné de services tiers (2 occurrences)
- CWE-918 : falsification de requête côté serveur (SSRF) (2 occurrences)
- Générer un SBOM CycloneDX dans un pipeline CI (2 occurrences)
- ASI07 : communication inter-agents non sécurisée (1 occurrence)
- Attaque XXE : entités externes XML, lecture de fichiers et SSRF (1 occurrence)
- Comment bloquer les requêtes côté serveur et la désérialisation (1 occurrence)
- Comment organiser une astreinte cybersécurité durable (1 occurrence)