Peut-on faire confiance à un webhook ? Liste de contrôle pour les applications auto-hébergées

Commencez par dresser l’inventaire des webhooks

Avant d’activer un webhook, identifiez les échanges et les effets qu’il peut déclencher. Les questions ci-dessous servent à évaluer une intégration ; elles ne confirment pas qu’une application donnée prend en charge les contrôles évoqués.

Examinez chaque adresse de réception séparément. Une application peut en utiliser plusieurs, avec des expéditeurs, des événements et des conséquences différents.

• Quel service externe est censé envoyer les requêtes, et comment l’application peut-elle vérifier son identité ?
• Quelle adresse, quelle instance et quel environnement sont concernés ?
• Quels types d’événements sont nécessaires, et quelles données chacun transmet-il ?
• Quelles modifications, notifications ou actions peuvent découler de chaque événement ?

Vérifiez l’authentification de l’expéditeur

Consultez la documentation officielle correspondant à l’application, à sa version et à l’intégration utilisée. Cherchez une description précise du mécanisme d’authentification, par exemple une vérification de signature ou un secret transmis dans un en-tête, sans présumer qu’un mécanisme particulier est disponible.

Si vous ne trouvez pas de méthode documentée pour vérifier l’expéditeur, notez cette incertitude. Une adresse difficile à deviner ou une connexion chiffrée ne suffisent pas, à elles seules, à établir quel contrôle l’application applique.

• Quel mécanisme est documenté, et où la vérification est-elle effectuée ?
• Que se passe-t-il lorsqu’une requête ne fournit pas l’information d’authentification attendue ou que celle-ci est invalide ?
• Le mécanisme est-il présent dans la version déployée et activé dans la configuration réelle ?
• Si un proxy ou un autre composant intervient, qui configure et vérifie ce contrôle ?

Examinez les événements et les données acceptés

Pour chaque type d’événement, vérifiez quelles données l’application attend et comment elle traite les valeurs reçues. Ne supposez pas que l’authentification de l’expéditeur valide automatiquement le contenu ou les actions demandées.

Déterminez si l’intégration permet de limiter les événements et les données au périmètre nécessaire. Vérifiez aussi comment sont traités les événements inconnus, les champs inattendus ou les requêtes mal formées.

• Quels champs et formats sont attendus pour chaque événement ?
• Existe-t-il des limites documentées concernant la taille ou la forme des requêtes ?
• Comment l’application vérifie-t-elle que les identifiants transmis concernent le compte ou l’espace de travail attendu ?
• Quels événements non prévus ou champs supplémentaires peuvent être reçus, et quel comportement leur est réservé ?

Demandez comment sont traités les doublons et les retards

Vérifiez dans la documentation de l’expéditeur et du destinataire si l’intégration prévoit un identifiant d’événement, un horodatage ou un autre mécanisme pour reconnaître les requêtes répétées ou anciennes. Ne supposez pas qu’une requête authentifiée ne peut pas être reçue plusieurs fois.

Établissez le comportement attendu en cas de doublon ou de retard, puis vérifiez-le dans un environnement adapté si cela est possible.

• L’intégration fournit-elle un identifiant ou un horodatage, et comment le destinataire les utilise-t-il ?
• Comment l’application réagit-elle à la réception répétée du même événement ?
• Un événement traité deux fois peut-il entraîner des modifications ou notifications en double ?
• Les retards ou les décalages d’horloge ont-ils un effet sur le traitement documenté ?

Évaluez les permissions et les secrets

Suivez le parcours d’un événement jusqu’aux actions qu’il déclenche. Vérifiez quels comptes, jetons ou automatisations interviennent et quelles permissions leur sont accordées ; les droits disponibles dépendent de l’application et de sa configuration.

Repérez aussi où sont conservés les secrets associés à l’intégration, qui peut y accéder et comment leur remplacement est documenté. Ne présumez pas qu’une application offre une procédure de rotation donnée.

• L’intégration peut-elle utiliser une identité dédiée, et quelles permissions cette identité possède-t-elle ?
• Quelles actions chaque événement peut-il déclencher, y compris dans les services connectés ?
• Où sont stockés les secrets et qui peut les consulter ou les modifier ?
• Quelle procédure l’application et le fournisseur documentent-ils pour remplacer un secret et vérifier que l’ancien n’est plus utilisé ?

Examinez les journaux et la répartition des responsabilités

Vérifiez ce que consignent l’application et les composants qui l’entourent. Les corps de requête et les en-têtes peuvent contenir des informations sensibles : déterminez si ces données sont enregistrées, qui peut consulter les journaux et combien de temps ils sont conservés.

Établissez également quel composant est responsable de chaque contrôle. L’application, le fournisseur externe, le proxy ou une couche d’intégration peuvent intervenir, mais la répartition dépend du déploiement et doit être vérifiée dans sa documentation.

Airbip exécute des instances d’applications sous forme de charges de travail Docker sur ses serveurs cloud et automatise le routage ainsi que les certificats TLS via Traefik et Let’s Encrypt. Ces capacités d’hébergement ne permettent pas, à elles seules, de conclure comment une application donnée authentifie ou traite ses webhooks.

• Les journaux contiennent-ils des corps de requête, des en-têtes, des signatures ou d’autres données sensibles ?
• Qui peut consulter les journaux et quelles règles de conservation ou de suppression s’appliquent ?
• Pour chaque contrôle examiné, quel composant en est responsable et que se passe-t-il s’il échoue ?
• Si la documentation ne permet pas de vérifier un contrôle nécessaire, quelle incertitude reste à résoudre avant d’activer l’intégration ?