Endurecimiento de seguridad: 2FA, protección SSRF, bloqueo de nodes, desactivación de la Public API
Cómo endurecer n8n: activar la 2FA, configurar la protección SSRF, bloquear nodes de riesgo con NODES_EXCLUDE y desactivar la Public API cuando no se utiliza.
Quien opera una instancia de n8n autoalojada asume por completo la responsabilidad de su protección, ya que n8n Cloud se ocupa automáticamente de parte de estas medidas de protección, mientras que un servidor propio no lo hace por sí solo. Solo en el apartado de configuración de seguridad de la documentación oficial de n8n hay más de una docena de capítulos individuales, desde la autenticación de dos factores hasta la Public API, pasando por la protección SSRF, que hasta ahora no se habían recopilado juntos de esta forma en alemán. Las cuatro palancas más importantes para la operación continua son: poner la 2FA a disposición y exigirla, activar la protección SSRF, bloquear nodes de riesgo mediante NODES_EXCLUDE y desactivar la Public API cuando nadie la necesite. Actualizado: julio de 2026.
Activar la autenticación de dos factores
n8n activa la función 2FA a nivel de instancia mediante la variable de entorno N8N_MFA_ENABLED, cuyo valor predeterminado es true. Con ello, los usuarios individuales pueden configurar por sí mismos la autenticación de dos factores en su configuración de cuenta personal; la documentación central no describe un interruptor central que la obligue simultáneamente para todas las cuentas. Importante en la práctica: una vez que un usuario ha activado la 2FA, n8n ignora, según la documentación, una desactivación posterior mediante la variable de entorno, por lo que la protección no puede anularse accidentalmente mediante un cambio de configuración.
- N8N_MFA_ENABLED: booleano, valor predeterminado true, controla si la 2FA está disponible en la cuenta del usuario.
- Sin marcha atrás: una vez que un usuario ha activado la 2FA, esta permanece activa aunque la variable de entorno se establezca después en false.
- Obligación organizativa: dado que n8n no impone la activación de forma centralizada, debe exigir internamente a su equipo que configure realmente la 2FA.
Protección SSRF contra accesos a sistemas internos
Server-Side Request Forgery significa que un node de workflow, por ejemplo el node HTTP Request, se utiliza indebidamente para enviar solicitudes a recursos de red internos, endpoints de metadatos en la nube o servicios localhost que en realidad no deberían ser accesibles desde el exterior. n8n ofrece para ello su propio mecanismo de protección desde la versión 2.12.0, que puede activarse mediante N8N_SSRF_PROTECTION_ENABLED=true. Cuando la protección está activa, n8n verifica las solicitudes HTTP salientes de los nodes controlados por el usuario frente a listas de permitidos y bloqueados configuradas, incluidos los destinos de redirección y la resolución DNS, para evitar los trucos de evasión habituales.
- Bloqueado por defecto: redes privadas como 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16, direcciones de loopback como 127.0.0.0/8, rangos link-local y varios espacios de direcciones reservados.
- Ampliar la lista de bloqueo: mediante N8N_SSRF_BLOCKED_IP_RANGES se pueden añadir rangos adicionales, por ejemplo N8N_SSRF_BLOCKED_IP_RANGES=default,100.0.0.0/8.
- Definir excepciones: N8N_SSRF_ALLOWED_HOSTNAMES permite nombres de host, incluidos comodines, N8N_SSRF_ALLOWED_IP_RANGES permite determinados rangos de IP, siendo el orden lista de permitidos de nombres de host antes de lista de permitidos de IP antes de lista de bloqueo de IP.
- No sustituye la seguridad de red: la protección actúa a nivel de aplicación y complementa los firewalls y los security groups, pero según la documentación no los sustituye.
Bloquear nodes de riesgo con NODES_EXCLUDE
No todos los nodes son adecuados para todos los grupos de usuarios. La variable de entorno NODES_EXCLUDE permite definir una lista de tipos de node que no son ni detectables ni utilizables para ningún usuario de la instancia. El valor se pasa como un array JSON de identificadores de node, por ejemplo NODES_EXCLUDE con el contenido ["n8n-nodes-base.executeCommand", "n8n-nodes-base.readWriteFile"]. La documentación menciona en particular el node Execute Command y el node Read/Write Files from Disk como candidatos típicos para entornos en los que no todos los usuarios son plenamente de confianza, ya que ambos permiten acceso directo al sistema host.
- Formato: array JSON como cadena, cada entrada es el nombre interno completo del node.
- Efecto: los nodes bloqueados no pueden encontrarse en la búsqueda de nodes ni utilizarse en workflows.
- Levantar los bloqueos predeterminados: algunos nodes como Execute Command ya están bloqueados de fábrica; quien quiera habilitarlos deliberadamente establece NODES_EXCLUDE explícitamente como un array vacío.
Desactivar la Public API cuando nadie la necesita
La Public REST API de n8n permite controlar programáticamente prácticamente todo lo que también es posible mediante la interfaz, es decir, crear workflows, disparar ejecuciones o gestionar credenciales. Esto es precisamente lo que la convierte en una superficie de ataque adicional cuando permanece activa sin usarse. Mediante N8N_PUBLIC_API_DISABLED=true desactiva completamente la Public API; la documentación lo recomienda expresamente si nadie utiliza realmente la API. Quien necesite la API pero no quiera mostrar públicamente la interfaz de documentación interactiva puede además establecer N8N_PUBLIC_API_SWAGGERUI_DISABLED=true, lo que solo desactiva el playground de la API, mientras la API en sí sigue siendo accesible.
- N8N_PUBLIC_API_DISABLED: desactiva por completo la Public API.
- N8N_PUBLIC_API_SWAGGERUI_DISABLED: solo oculta la interfaz interactiva de Swagger, la API en sí sigue funcionando.
Otros elementos de la documentación de seguridad
Los cuatro puntos mencionados son los que ofrecen la mayor palanca para el día a día, pero no cubren todo el espectro. La documentación de seguridad de n8n trata además, entre otras cosas, el Single Sign-On, la obligación de verificación por correo electrónico de las cuentas nuevas, el cifrado TLS de la conexión, la rotación periódica de las claves de cifrado, el descifrado JWE de tokens OAuth 2.0, el enmascarado de los datos de ejecución, la protección de los task runners y la desactivación de la telemetría. n8n recomienda además ejecutar periódicamente una auditoría de seguridad integrada, que comprueba automáticamente muchos de estos ajustes y enumera los puntos pendientes. Quien no quiera mantener estos ajustes por sí mismo encontrará, en el marco de nuestra consultoría de n8n apoyo para la configuración y la operación continua, en la que también decimos honestamente dónde la automatización sola no basta y siguen siendo necesarias reglas organizativas dentro del equipo.
Preguntas frecuentes sobre el endurecimiento de seguridad de n8n
¿Debo poder imponer la 2FA a todos los usuarios?
n8n activa la función a nivel de instancia mediante N8N_MFA_ENABLED, pero la configuración real se realiza por cuenta de usuario en los ajustes personales. La documentación central no describe un interruptor central que haga la 2FA obligatoria de inmediato para todas las cuentas, por lo que sigue siendo tarea suya exigir organizativamente al equipo que la active.
¿Sustituye la protección SSRF a un firewall?
No. La protección SSRF actúa a nivel de aplicación y verifica las solicitudes salientes de los nodes de workflow, complementando así los controles de red como firewalls y security groups, pero según la documentación no los sustituye en absoluto.
¿Qué nodes debería bloquear por defecto?
La documentación menciona el node Execute Command y el node Read/Write Files from Disk como candidatos típicos para NODES_EXCLUDE, porque ambos permiten acceso directo al sistema host subyacente. Qué otros nodes son de riesgo depende de su grupo concreto de usuarios.
¿Realmente necesito la Public API?
Solo si controla n8n de forma programática, por ejemplo desde sus propios scripts, otros sistemas o pipelines de CI/CD. Si la API no se utiliza activamente, la documentación recomienda desactivarla por completo mediante N8N_PUBLIC_API_DISABLED.
Fuentes: Resumen de seguridad de n8n, Autenticación de dos factores, Activar la protección SSRF, Bloquear nodes, Desactivar la Public API
NordFlux UG (haftungsbeschränkt)
NordFlux crea empleados digitales para las organizaciones: automatizaciones y agentes KI que asumen el trabajo repetitivo. Usted mantiene el control.
¿Preguntas concretas sobre automatización o IA?
En un análisis inicial gratuito hablamos directamente de su caso. Sin compromiso.