Suscribirse al número mínimo de eventos
Debes suscribirte solo a los eventos de webhook que necesitas. Esto reducirá la cantidad de trabajo que debe hacer el servidor. Para más información sobre cómo suscribirse a los eventos, consulta Crear webhooks y Editar los webhooks.
Uso de un secreto de webhook
Warning
Para evitar la exposición accidental de información confidencial, no incluyas información confidencial en la dirección URL de carga. Esto incluye tus propias claves de API y otras credenciales de autenticación. En su lugar, para validar que las entregas de webhook se enviaron mediante GitHub y no se han alterado, usa un secreto de webhook. Para más información, consulta Validación de entregas de webhook.
El secreto de webhook debe ser una cadena aleatoria de texto con alta entropía. Debes almacenar de forma segura el secreto de webhook de forma que el servidor pueda acceder.
Uso de la comprobación de HTTPS y SSL
Debes asegurarte de que el servidor usa una conexión HTTPS. De forma predeterminada, GitHub comprobará los certificados SSL al entregar webhooks. En GitHub se recomienda dejar habilitada la comprobación de SSL.
Direcciones IP permitidas de GitHub
Puedes configurar una lista de direcciones IP permitidas para el servidor y agregar las direcciones IP que GitHub usa para las entregas de webhook. Esto puede bloquear las solicitudes suplantadas al servidor.
Puedes usar el punto de conexión GET /meta para buscar la lista actual de GitHub direcciones IP. Para más información, consulta Puntos de conexión de la API de REST para metadatos. GitHub ocasionalmente realiza cambios en sus direcciones IP, por lo que debes actualizar la lista de direcciones IP permitidas periódicamente.
Para más información, consulta Acerca de las direcciones de IP de GitHub.
Responder en 10 segundos
El servidor debe responder con una respuesta 2XX dentro de 10 segundos tras recibir una entrega de webhook. Si el servidor tarda más de eso en responder, GitHub finaliza la conexión y considera la entrega fallida.
Para responder a tiempo, es posible que desees configurar una cola para procesar cargas de webhook de forma asincrónica. El servidor puede responder cuando recibe el webhook y, a continuación, procesar la carga en segundo plano sin bloquear futuras entregas de webhook. Por ejemplo, puedes usar servicios como Hookdeck o bibliotecas como Resque (Ruby), RQ (Python) o RabbitMQ (Java).
Verifica el tipo de evento y de acción antes de procesar el evento
Hay varios tipos de eventos de webhook, y cada evento puede tener varios tipos de acción. GitHub continúa añadiendo nuevos tipos de eventos y nuevas acciones a los tipos de eventos existentes. La aplicación debe comprobar el tipo de evento y la acción de una carga de webhook antes de procesar la carga. Para determinar el tipo de evento, puedes usar el encabezado de solicitud X-GitHub-Event. Para determinar el tipo de acción, puede usar la clave action de nivel superior en la carga del evento.
Volver a entregar entregas fallidas
Si el servidor deja de funcionar, debes volver a entregar los webhooks que faltan una vez que se realiza la copia de seguridad del servidor. Para más información, consulta Entregar webhooks.
Use el encabezado X-GitHub-Delivery
En un ataque de reinyección, un actor malintencionado intercepta la entrega de un webhook y la reenvía. Para protegerte frente a ataques de reinyección, puedes usar el encabezado X-GitHub-Delivery para asegurarte de que cada entrega sea única por evento.
Note
Si solicitas una nueva entrega, el encabezado X-GitHub-Delivery será el mismo que en la entrega original.