Bonnes pratiques pour sécuriser les webhooks

Les webhooks sont l’un des meilleurs moyens de transmettre des informations sur des événements ponctuels d’un système à un autre. Contrairement à des méthodes comme l’interrogation HTTP — qui consiste pour le client à demander à répétition des informations au serveur — les webhooks sont déclenchés par des événements.

Ils sont donc simples et efficaces. Un client peut s’abonner à un webhook afin qu’un message soit envoyé à un point de terminaison chaque fois qu’un événement spécifique se produit.

Cependant, comme les webhooks impliquent souvent l’envoi de messages vers un point de terminaison public sur Internet, ils peuvent présenter des risques de sécurité. Sans mesures de sécurité adéquates, un attaquant peut lire et modifier les messages, voire usurper complètement votre identité. Il faut donc prendre toutes les mesures possibles pour atteindre le niveau de sécurité nécessaire lors de l’exploitation d’un service de webhook.

Dans cet article, nous présentons les pratiques les plus efficaces pour sécuriser les webhooks et partager des données entre applications sans créer une vaste surface d’attaque.

8 bonnes pratiques de sécurité à suivre lors de la création de webhooks

1. Chiffrez les données transmises par les webhooks

2. Signez les webhooks

3. Authentifiez les connexions

4. Ajoutez des horodatages aux messages

5. Utilisez l’épinglage de certificat

6. N’utilisez pas les webhooks pour transmettre des données sensibles

7. Consignez tous les messages envoyés par webhook

8. Utilisez un modèle d’abonnement avec une date d’expiration

Lors de la création d’une implémentation de webhook, mieux vaut ne pas s’appuyer sur une seule pratique de sécurité. Il faut plutôt combiner plusieurs approches pour protéger le système, même si un attaquant parvient à contourner certaines de nos mesures de sécurité.

Au minimum, nous devons utiliser le chiffrement afin de préserver la confidentialité des messages échangés avec les clients, ainsi qu’une authentification mutuelle pour que le client et le serveur puissent vérifier l’identité de leur interlocuteur.

Chiffrez les données transmises par les webhooks

Nous ne pouvons pas empêcher des acteurs malveillants d’intercepter nos messages, mais nous pouvons les empêcher d’en lire le contenu. Pour sécuriser facilement toutes les communications, utilisez HTTPS plutôt que HTTP.

HTTPS est très facile à utiliser et il y a peu, voire aucune raison de ne pas y recourir. HTTPS chiffre toutes les données, ce qui complique considérablement leur accès par un tiers.

Signez les webhooks

Des acteurs malveillants peuvent intercepter des messages envoyés sur Internet et en modifier le contenu à leur avantage. Pour éviter toute modification indésirable, nous devons signer nos messages. Pour ce faire, nous pouvons utiliser un code d’authentification de message à clé, ou HMAC, qui associe un algorithme de hachage à un code secret ou à une clé partagés par les deux parties.

Les HMAC appliquent une fonction de hachage spécifique à chaque message. Le consommateur du webhook peut ainsi vérifier l’authenticité et l’intégrité d’un message en le comparant à son hachage.

Pour en savoir plus sur la signature des webhooks, consultez cet article utile de Twilio.

Authentifiez les connexions

Les points de terminaison des webhooks sont souvent publics et accessibles à tous sur Internet. Cette accessibilité expose les consommateurs de webhooks à plusieurs vulnérabilités, notamment aux attaques par déni de service. Pour résoudre ce problème, les consommateurs de webhooks doivent authentifier la source des messages. Ils peuvent le faire à l’aide d’un nom d’utilisateur et d’un mot de passe ou d’un jeton d’authentification.

Il est également judicieux d’authentifier le consommateur pour s’assurer que le message arrive à la bonne destination.

Ajoutez des horodatages à vos messages

Nous pouvons horodater nos messages pour contribuer à prévenir les attaques par rejeu. Ces attaques ne lisent pas les messages et ne les modifient pas, mais elles peuvent intercepter un message légitime et chiffré, puis le renvoyer au moment opportun.

En horodatant nos messages, nous permettons au client de vérifier que le message reçu est récent et non un message envoyé il y a plusieurs semaines. Comme nos messages sont également signés, l’attaquant ne peut ni modifier l’horodatage ni conserver le message pour le rejouer.

Utilisez l’épinglage de certificat

Si notre client reçoit une connexion d’un serveur web qui présente un certificat de confiance pour notre API, cela ne signifie pas que le site web (et le certificat) nous appartient. Un attaquant potentiel peut copier notre API et lui associer un certificat de confiance. Il peut alors intercepter le message légitime et envoyer le sien à la place.

L’épinglage de certificat est une solution à ce problème. Si l’événement provient chaque fois du même serveur, le client peut épingler le certificat de ce serveur dans le code. Cela consiste à coder en dur le certificat ou son hachage (empreinte) dans l’application, puis à le comparer au certificat fourni à chaque connexion.

Il faut toutefois faire preuve de prudence avec cette technique, car elle repose sur des paramètres codés en dur. En cas de changement ou de révocation du certificat, le client risque de ne pas pouvoir le mettre à jour assez rapidement.

Consultez la documentation de Mozilla pour voir un exemple d’épinglage de certificat.

N’utilisez pas les webhooks pour transmettre des données sensibles

Même sécurisés, les webhooks ne conviennent pas à la transmission de données sensibles comme des mots de passe ou des numéros de carte bancaire. En général, ils servent à envoyer des notifications sur des événements. Si vous incluez des données sensibles dans les messages envoyés par webhook, vous devriez revoir votre cas d’usage.

Consignez tous les messages envoyés par webhook

Nous pouvons consigner les messages des webhooks à l’aide d’une solution interne ou tierce. Les journaux enregistrent chaque message envoyé, ce qui est utile lors des audits. En cas d’incident de sécurité, nous pouvons également consulter tous les messages envoyés et les connexions établies. La surveillance des journaux peut aussi nous aider à repérer les comportements suspects — comme les échecs de livraison — avant qu’un incident de sécurité ne se produise.

La consignation des messages des webhooks améliore aussi l’efficacité. Par exemple, nous pouvons désabonner les utilisateurs qui ne reçoivent plus nos journaux depuis longtemps, afin de maintenir une liste exacte et à jour. Consultez cette vidéo de NearForm pour en savoir plus sur la consignation des messages des webhooks. Pour un bon outil de journalisation des webhooks, découvrez également ce logger Node.js.

Utilisez un modèle d’abonnement avec une date d’expiration

Il est préférable de permettre aux utilisateurs de définir une date d’expiration pour leur abonnement. Même si cette date a un effet limité à elle seule, son association à d’autres pratiques de sécurité ajoute une couche de protection.

Combinée à différentes méthodes de chiffrement, d’authentification et d’autorisation, la limitation de la durée pendant laquelle un serveur ou un client dispose de privilèges contribue à renforcer la sécurité. De plus, les dates d’expiration réduisent le temps dont dispose un acteur malveillant pour trouver une faille dans notre sécurité (comme des identifiants volés), puisque le client doit renouveler son abonnement à son expiration.

Renforcer la sécurité des webhooks

Le chiffrement des messages des webhooks constitue la base qui permet aux clients d’en vérifier la validité. D’autres pratiques de sécurité viennent compléter ce principe et, combinées, offrent une protection plus complète.

N’oubliez pas que les webhooks servent généralement à informer les clients des événements qui se produisent dans votre système. La plupart de ces événements, comme les nouvelles demandes de pull request sur GitHub ou les nouveaux abonnés, ne devraient pas présenter de risque. Les attaquants auront donc peu d’intérêt à intercepter ces communications. Il est fortement recommandé d’éviter d’envoyer des données hautement sensibles par webhook.

Une approche globale de la sécurité commence par le choix de mesures adaptées au domaine de votre application et à la nature des informations que vous envoyez. Les mises à jour concernant des événements à venir, par exemple, nécessitent moins de mesures de sécurité que les messages contenant des informations détaillées sur des clients individuels. En adaptant votre approche et en superposant plusieurs couches de sécurité, vous pouvez protéger plus sereinement votre code et les données de vos clients contre les différents types de vulnérabilités auxquels nous sommes confrontés aujourd’hui.