Skip to main content

Esta versión de GitHub Enterprise Server se discontinuó el 2024-09-25. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

Procedimientos recomendados para usar webhooks

Sigue estos procedimientos recomendados para mejorar la seguridad y el rendimiento al usar webhooks.

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 suscribirse a los eventos, consulte "Crear webhooks" y "Editar los webhooks".

Uso de un secreto de webhook

Debes establecer un secreto de webhook para el webhook y comprobar que la firma de cada entrega de webhook coincide con el secreto. Esto ayuda a garantizar que la entrega del webhook procede de GitHub. Para obtener más información, vea «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.

Responder en 30 segundos

El servidor debe responder con una respuesta 2XX dentro de 30 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 obtener más información, vea «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.

Nota: Si solicita una nueva entrega, el encabezado X-GitHub-Delivery será el mismo que en la entrega original.

Información adicional