Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2024-09-25. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Melhores práticas para usar webhooks

Siga estas melhores práticas para melhorar a segurança e o desempenho quando usar webhooks.

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, consulte "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 obter mais informações, 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.

Responder em até 30 segundos

Seu servidor deve dar uma resposta 2XX em até 30 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 obter mais informações, 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.

Leitura adicional