Seguridad en webhooks con n8n: guía completa

El problema de los webhooks públicos

n8n expone webhooks en URLs predecibles. Sin protección, cualquier actor puede disparar tus flujos de automatización con datos arbitrarios. En producción esto es inaceptable.

Capa 1: Header de autenticación

La defensa mínima es un token secreto en el header de cada request:

// En n8n: webhook node → Authentication → Header Auth
// Header name: x-audit-token
// Header value: tu-token-largo-y-aleatorio

// Verificación en el webhook node:
{{ $request.headers['x-audit-token'] === process.env.WEBHOOK_TOKEN }}

Capa 2: Validación de IP de origen

Si el webhook solo debe ser llamado por Supabase o por un servidor específico, restringir por IP en el nginx que hace de proxy:

location /webhook/ {
    allow 52.16.0.0/14;  # Supabase EU
    allow 76.13.136.151; # Tu VPS
    deny all;
    proxy_pass http://localhost:5678;
}

Capa 3: Validación de payload

Nunca confiar en el payload del webhook. Validar tipos, longitudes y valores esperados antes de ejecutar operaciones de negocio. n8n permite agregar nodos de validación antes de la lógica principal.

Logging de auditoría

Todo webhook ejecutado debe quedar registrado: timestamp, IP de origen, payload hash, resultado de la ejecución. En Supabase esto es trivial con un INSERT en una tabla de audit_log.

Rate limiting

Usar nginx o Cloudflare para limitar requests por IP. Para webhooks internos, 10 requests/minuto es suficiente. Para webhooks públicos (formularios de contacto), 3 requests/minuto por IP previene spam.

¿Querés implementar esto en tu empresa? Escribinos. Diagnóstico de 30 minutos sin compromiso.