Meilleures pratiques en matière d’utilisation des webhooks

Abonnez-vous uniquement aux événements de webhook dont vous avez besoin. Cet abonnement réduit la quantité de travail nécessaire à votre serveur. Pour plus d’informations sur l’abonnement aux événements, consultez « Création de webhooks » et « Édition de webhooks ».

Utiliser un secret de webhook

Avertissement

Pour éviter l’exposition accidentelle d’informations confidentielles, n’incluez pas d’informations confidentielles dans l’URL de votre charge utile. Cela comprend vos propres clés d’API et autres informations d’authentification. Au lieu de cela, pour confirmer que les livraisons de webhook ont été envoyées par GitHub et n’ont pas été altérées, utilisez un secret de webhook. Pour plus d’informations, consultez « Validation des livraisons de webhook ».

Le secret Webhook doit être une chaîne de texte aléatoire avec une entropie élevée. Vous devez stocker en toute sécurité votre secret webhook de manière à ce que votre serveur puisse y accéder.

Utilisez la vérification HTTPS et SSL

Vous devez vous assurer que votre serveur utilise une connexion HTTPS. Par défaut, GitHub vérifie les certificats SSL pendant la livraison de webhooks. GitHub recommande de laisser la vérification SSL activée.

Répondez dans 30 secondes

Votre serveur doit renvoyer une réponse 2XX dans un délai de 30 secondes après la réception d’une livraison de webhook. Si votre serveur prend plus de temps qu’indiqué pour répondre, alors GitHub arrête la connexion et considère la livraison comme un échec.

Pour répondre en temps opportun, vous pouvez configurer une file d’attente pour traiter les charges utiles webhook de manière asynchrone. Votre serveur peut répondre lorsqu’il reçoit le webhook, puis traiter la charge utile en arrière-plan sans bloquer les futures livraisons de webhook. Par exemple, vous pouvez utiliser des services tels que Hookdeck ou des bibliothèques comme Resque (Ruby), < >c2>RQ (Python) ou RabbitMQ (Java).

Vérifier le type d’événement et l’action avant de traiter l’événement

Il existe plusieurs types d’événements webhook, et plusieurs événements peuvent comprendre plusieurs types d’actions. GitHub continue d’ajouter de nouveaux types d’événements et de nouvelles actions aux types d’événements existants. Votre application doit vérifier le type d’événement ainsi que l’action d’une charge utile de webhook avant de traiter cette charge utile. Pour déterminer le type d’événement, vous pouvez utiliser l’en-tête de requête X-GitHub-Event. Pour déterminer le type d’action, vous pouvez utiliser la clé de premier niveau action dans la charge utile de l’événement.

Renouveler les livraisons manquées

Si votre serveur tombe en panne, vous devez renvoyer les webhooks non livrés une fois que votre serveur est de nouveau opérationnel. Pour plus d’informations, consultez « Nouvelle livraison des webhooks ».

Utiliser l’en-tête `X-GitHub-Delivery`

Lors d’une attaque par rejeu, un acteur malveillant intercepte une livraison de webhook puis la renvoie. Afin de vous prémunir contre les attaques par rejeu, vous pouvez utiliser l’en-tête X-GitHub-Delivery pour garantir que chaque livraison est unique pour un événement donné.

Remarque

Si vous demandez une redelivery, l’en-tête X-GitHub-Delivery sera identique à celui de la remise d’origine.

Pour aller plus loin

        [AUTOTITLE](/rest/guides/best-practices-for-integrators)

        [AUTOTITLE](/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app)

Meilleures pratiques en matière d’utilisation des webhooks

Dans cet article