Inscreva-se no número mínimo de eventos
Você só deve se inscrever nos eventos de webhook de que necessita. Isso reduzirá a quantidade de trabalho que seu servidor precisará executar. Para obter mais informações sobre como assinar eventos, confira Criar webhooks e Editando webhooks.
Usar um segredo de webhook
Warning
Para evitar a exposição acidental de informações confidenciais, não inclua esse tipo de informação na URL de conteúdo. Isso inclui suas chaves de API e outras credenciais de autenticação. Em vez disso, para validar que as entregas de webhook foram enviadas pelo GitHub e não foram adulteradas, use um segredo de webhook. Para saber mais, confira Validação de entregas de webhooks.
O segredo de webhook deve ser uma cadeia de caracteres aleatória de texto com alta entropia. Você deve armazenar com segurança seu segredo de webhook de uma maneira que seu servidor possa acessar.
Usar verificação HTTPS e SSL
Você deve garantir que seu servidor use uma conexão HTTPS. Por padrão, o GitHub verificará certificados SSL ao entregar webhooks. O GitHub recomenda que deixe a verificação de SSL habilitada.
Permitir endereços IP do GitHub
Você pode configurar uma lista de IP permitidos para seu servidor e adicionar os endereços IP que o GitHub usa para entregas de webhook. Isso pode bloquear solicitações falsificadas para o servidor.
Você pode usar o ponto de extremidade GET /meta para encontrar a lista atual de endereços IP do GitHub. Para saber mais, confira Pontos de extremidade da API REST para metadados. O GitHub ocasionalmente faz alterações nos seus endereços IP. Portanto, você deve atualizar sua lista de IP permitidos periodicamente.
Para saber mais, confira Sobre os endereços IP do GitHub.
Responder em até 10 segundos
Seu servidor deve dar uma resposta 2XX em até 10 segundos depois de receber uma entrega de webhook. Se o servidor demorar mais do que isso para responder, o GitHub terminará a conexão e considerará que houve falha na entrega.
Para responder em tempo hábil, convém configurar uma fila para processar conteúdo de webhook de forma assíncrona. Seu servidor pode responder ao receber o webhook e, em seguida, processar o conteúdo em segundo plano sem bloquear futuras entregas de webhook. Por exemplo, você pode usar serviços, como Hookdeck, ou bibliotecas, como Resque (Ruby), RQ (Python) ou RabbitMQ (Java).
Verifique o tipo de evento e a ação antes de processar o evento
Há vários tipos de evento de webhook e muitos eventos podem ter vários tipos de ação. O GitHub continua a adicionar novos tipos de evento e novas ações aos tipos de evento existentes. Seu aplicativo deve verificar o tipo de evento e a ação de um conteúdo de webhook antes de processar o conteúdo. Para determinar o tipo de evento, você pode usar o cabeçalho da solicitação X-GitHub-Event. Para determinar o tipo de ação, você pode usar a chave action de nível superior no conteúdo do evento.
Fazer nova entrega de entregas ignoradas
Se o servidor ficar inoperante, você deverá fazer uma nova entrega dos webhooks ignorados assim que o servidor retornar. Para saber mais, confira Entregar webhooks novamente.
Use o cabeçalho X-GitHub-Delivery
Em um ataque de reprodução, um agente mal-intencionado intercepta uma entrega de webhook e reenvia a entrega. Para se proteger contra ataques de reprodução, você pode usar o cabeçalho X-GitHub-Delivery para garantir que cada entrega seja exclusiva por evento.
Note
Se você solicitar uma nova entrega, o cabeçalho X-GitHub-Delivery será o mesmo da entrega original.