Entender y proteger los webhooks

Un webhook es, en esencia, una puerta abierta en tu sistema n8n: en cuanto un servicio externo envía una solicitud HTTP a la URL generada por el nodo Webhook, el flujo de trabajo asociado se inicia automáticamente, sin programación y sin clic manual. Precisamente esta apertura hace que los webhooks sean tan útiles para integraciones con Stripe, GitHub, herramientas de formularios o aplicaciones propias. Pero también convierte la URL en un punto de ataque si no hay autenticación, filtro de IP ni verificación de firma de por medio. Quien conozca o adivine la URL puede activar el flujo de trabajo.

Este artículo muestra la estructura del nodo Webhook en n8n, los métodos de autenticación integrados, la lista blanca de IP como capa de protección adicional y la configuración detrás de un reverse proxy, un punto que suele generar confusión en las instancias de n8n autoalojadas. Actualizado: julio de 2026.

Cómo está estructurado el nodo Webhook

Según la documentación de n8n sobre el nodo Webhook, el nodo admite seis métodos HTTP: DELETE, GET, HEAD, PATCH, POST y PUT. En el campo Path defines la ruta de la URL, ya sea libremente o con marcadores como `/:variable` para segmentos dinámicos. Sin una entrada propia, n8n genera una ruta aleatoria, lo que evita colisiones con otros flujos de trabajo.

Para la respuesta hay varias opciones:

• Immediately: El webhook responde de inmediato con el mensaje de que el flujo de trabajo se ha iniciado, sin esperar a que termine.
• When Last Node Finishes: La respuesta contiene los datos del último nodo ejecutado.
• Using Respond to Webhook Node: Un nodo propio dentro del flujo de trabajo controla de forma específica el código de estado, los encabezados y el cuerpo de la respuesta.
• Streaming response: Para nodos con soporte de streaming, la respuesta puede transmitirse en tiempo real.

Importante en la práctica: según la documentación, n8n solo registra una combinación de ruta y método HTTP a la vez. Dos flujos de trabajo activos con la misma ruta y el mismo método se bloquean mutuamente; uno debe desactivarse, o bien cambiar la ruta o el método.

Autenticación directamente en el nodo Webhook

Antes de pensar en filtros de IP o reglas de reverse proxy, deberías usar la autenticación integrada del nodo Webhook. Según la documentación sobre las credenciales de Webhook hay cuatro opciones disponibles:

• Basic Auth: El servicio que llama debe enviar un nombre de usuario y una contraseña en el encabezado Authorization. Fácil de configurar, pero solo tiene sentido combinado con HTTPS, ya que no aporta cifrado adicional.
• Header Auth: Defines un nombre de encabezado, por ejemplo `X-API-Key`, y un valor secreto. n8n comprueba cada solicitud entrante en busca de exactamente este encabezado. Este método encaja bien con servicios que ya envían una clave de API.
• JWT Auth: La solicitud debe contener un JSON Web Token firmado digitalmente. n8n verifica la firma mediante una frase de contraseña o una clave PEM que guardas en la credencial.
• None: Sin verificación, se acepta cualquier solicitud con la ruta correcta. Este ajuste es adecuado como mucho para pruebas breves, no para flujos de trabajo en producción.

La documentación deja claro un punto importante: el método elegido debe coincidir con lo que realmente envía el servicio que llama. Un webhook de GitHub, por ejemplo, suele firmar las solicitudes mediante una firma HMAC en el encabezado, que puedes comprobar adicionalmente a la Header Auth en un nodo Code, si quieres asegurar más allá de la simple autenticación del nodo.

La lista blanca de IP como capa de protección adicional

Además de la autenticación, el nodo Webhook ofrece la opción IP(s) Whitelist. Allí introduces una lista de direcciones IP permitidas separadas por comas; según la documentación, n8n responde con un error 403 a las solicitudes de direcciones no incluidas en la lista. Si el campo se deja vacío, se permiten todas las direcciones.

En la práctica, la lista blanca de IP funciona mejor como segunda capa junto con Header Auth o JWT Auth, no como protección única: si un servicio como Stripe o GitHub tiene rangos de IP de origen fijos, los introduces y bloqueas así todo lo demás por defecto. Para servicios con rangos de IP cambiantes o poco claros, la verificación por encabezado o JWT sigue siendo el método más fiable. Así mantienes el control sobre quién puede siquiera alcanzar el flujo de trabajo antes de que empiece a ejecutarse la lógica propiamente dicha.

Configurar correctamente los webhooks detrás de un reverse proxy

Si n8n está autoalojado detrás de un reverse proxy, por ejemplo Caddy, Nginx o Traefik, la detección automática de la URL deja de funcionar de forma fiable: n8n suele ejecutarse internamente en el puerto 5678, mientras que el proxy expone la aplicación hacia el exterior a través del puerto 443. Según la documentación de n8n sobre la configuración de la URL de webhook detrás de un reverse proxy esto se resuelve con dos variables de entorno:

• WEBHOOK_URL: Define la dirección completa y accesible públicamente que n8n muestra en el editor y registra ante servicios externos, por ejemplo `https://n8n.ejemplo.es/`.
• N8N_PROXY_HOPS: Debe establecerse en el número de proxies previos, normalmente 1. Con esto, n8n interpreta correctamente los encabezados reenviados por un proxy.

El propio proxy debe reenviar los encabezados `X-Forwarded-For`, `X-Forwarded-Host` y `X-Forwarded-Proto`. Si falta esta configuración, la lista blanca de IP de la sección anterior puede quedar sin efecto, porque n8n solo ve entonces la dirección interna del proxy en lugar de la IP real del remitente. Según la documentación de n8n, esta relación es precisamente una de las fuentes de error más frecuentes: se rechazan IP en la lista blanca aunque la lista esté correctamente mantenida, porque falta N8N_PROXY_HOPS o está mal configurado.

No confundir la URL de prueba con la de producción

Cada nodo Webhook genera dos URL distintas. La URL de prueba muestra los datos entrantes en el editor en cuanto haces clic en Listen for Test Event dentro del nodo, pero según la documentación permanece activa solo 120 segundos. La URL de producción entra en efecto solo cuando se publica el flujo de trabajo, pero entonces ya no muestra los datos en el editor, sino únicamente en la pestaña Executions.

Un error típico en la práctica: un servicio externo se configura durante el desarrollo con la URL de prueba, porque ofrece retroalimentación visible en el editor. Después de publicar el flujo de trabajo, el webhook deja de funcionar, porque el servicio sigue apuntando a la antigua URL de prueba en lugar de a la URL de producción. Por eso, antes de cada puesta en producción, comprueba si realmente está guardada la URL de producción en el sistema que llama. Quien utiliza n8n como empleada digital autoalojada y valora una seguridad de webhooks limpia y trazable encontrará en la consultoría de n8n de NordFlux apoyo para la configuración, la autenticación y la configuración del reverse proxy.

Preguntas frecuentes

¿Basta con Header Auth para asegurar un webhook?

Para muchas automatizaciones internas, Header Auth mediante HTTPS es suficiente, siempre que el valor secreto sea lo bastante largo y no adivinable. Para integraciones críticas en cuanto a seguridad, por ejemplo proveedores de pago, se recomienda añadir además una lista blanca de IP o una verificación de firma como HMAC en un nodo Code posterior.

¿Por qué mi dirección IP en la lista blanca sigue siendo bloqueada?

Normalmente se debe a un N8N_PROXY_HOPS ausente o mal configurado, cuando n8n se ejecuta detrás de un reverse proxy. Sin esta variable, n8n no ve la IP real del remitente, sino la dirección interna del proxy, y la compara erróneamente con la lista blanca.

¿Puedo colocar varios flujos de trabajo en la misma ruta de webhook?

No, según la documentación de n8n solo se puede registrar un webhook por cada combinación de ruta y método HTTP a la vez. Para varios disparadores en la misma ruta, debes usar métodos HTTP diferentes o adaptar la ruta.

¿Qué ocurre si sigo usando la URL de prueba después del desarrollo?

La URL de prueba solo está activa durante 120 segundos después de hacer clic en Listen for Test Event y muestra los datos en el editor. Después de publicar el flujo de trabajo, los sistemas que llaman deben cambiarse a la URL de producción, de lo contrario sus solicitudes no llegan a ningún sitio.

¿Tengo que usar JWT Auth si el servicio que llama no lo ofrece?

No, el método de autenticación siempre depende de lo que realmente admita el servicio que llama. Si un servicio solo ofrece una simple clave de API, Header Auth encaja mejor que JWT Auth, que requiere un token firmado.