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.
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.
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.
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.
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.
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.
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.
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.
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.
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 crea empleados digitales para las organizaciones: automatizaciones y agentes KI que asumen el trabajo repetitivo. Usted mantiene el control.
Los Task Runners de n8n ejecutan los nodos Code de forma aislada en lugar de en el proceso principal. Así funcionan el modo interno y externo.
Pasar de self-hosted al n8n Cloud: el esfuerzo de mantenimiento baja, pero el control tambien. Que no se traslada automaticamente en nodos y credenciales.
Shopware 6 no tiene un node nativo de n8n. Así conectas pedidos, clientes y stock mediante la Admin API y el HTTP Request Node.
2FA, protección SSRF y nodos bloqueados son solo el principio: una instancia de n8n segura exige mantenimiento continuo, actualizaciones y atención a cada nueva superficie de ataque. NordFlux opera n8n como servicio gestionado y se encarga del endurecimiento, la supervisión y las actualizaciones por usted. En una primera conversación evaluamos dónde es vulnerable su instancia hoy.
