Security Hardening: 2FA, SSRF Protection, Blocking Nodes, Disabling the Public API

Anyone running a self-hosted n8n instance bears full responsibility for securing it themselves, because n8n Cloud automatically handles part of this protection, while a self-managed server does not do so on its own. In the security configuration section of the official n8n documentation alone there are more than a dozen individual chapters, from two-factor authentication through SSRF protection to the Public API, that have not previously been bundled together in this form anywhere in German. The four most important levers for ongoing operation are: making 2FA available and requiring it, enabling SSRF protection, locking down risky nodes via NODES_EXCLUDE, and disabling the Public API when nobody needs it. As of: July 2026.

Enable two-factor authentication

n8n enables the 2FA feature instance-wide via the environment variable N8N_MFA_ENABLED, which defaults to true. This allows individual users to set up two-factor authentication themselves in their personal account settings, but a central switch that enforces it for all accounts at once is not described in the core documentation. Important in practice: once a user has enabled 2FA, n8n ignores a later attempt to disable it via the environment variable according to the documentation, so the protection cannot be accidentally undone by a configuration change.

• N8N_MFA_ENABLED: Boolean, default value true, controls whether 2FA is available at all in the user account.
• No way back: Once a user has activated 2FA, it remains in place even if the environment variable is later set to false.
• Organizational obligation: Since n8n does not centrally enforce activation, you must require your team internally to actually set up 2FA.

SSRF protection against access to internal systems

Server-Side Request Forgery means that a workflow node, such as the HTTP Request node, is misused to send requests to internal network resources, cloud metadata endpoints, or localhost services that should not actually be reachable from outside. n8n has offered its own protection mechanism for this since version 2.12.0, which can be enabled via N8N_SSRF_PROTECTION_ENABLED=true. When the protection is active, n8n checks outgoing HTTP requests from user-controlled nodes against configured allow and block lists, including redirect targets and DNS resolution, to prevent typical bypass tricks.

• Blocked by default: Private networks such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, loopback addresses such as 127.0.0.0/8, link-local ranges, and various reserved address spaces.
• Extend the block list: Additional ranges can be added via N8N_SSRF_BLOCKED_IP_RANGES, for example N8N_SSRF_BLOCKED_IP_RANGES=default,100.0.0.0/8.
• Define exceptions: N8N_SSRF_ALLOWED_HOSTNAMES allows hostnames including wildcards, N8N_SSRF_ALLOWED_IP_RANGES allows specific IP ranges, with the order being hostname allowlist before IP allowlist before IP blocklist.
• No substitute for network security: The protection works at the application level and complements firewalls and security groups, but according to the documentation does not replace them.

Lock down risky nodes with NODES_EXCLUDE

Not every node is suitable for every user group. The environment variable NODES_EXCLUDE lets you define a list of node types that are neither discoverable nor usable for any user of the instance. The value is passed as a JSON array of node identifiers, for example NODES_EXCLUDE with the content ["n8n-nodes-base.executeCommand", "n8n-nodes-base.readWriteFile"]. The documentation specifically names the Execute Command node and the Read/Write Files from Disk node as typical candidates for environments in which not all users are fully trusted, since both allow direct access to the host system.

• Format: JSON array as a string, each entry is the full internal node name.
• Effect: Blocked nodes can neither be found in the node search nor used in workflows.
• Lifting default blocks: Some nodes such as Execute Command are already blocked by default; anyone who wants to deliberately allow them sets NODES_EXCLUDE explicitly to an empty array.

Disable the Public API when nobody needs it

The n8n Public REST API allows practically everything that can also be done through the interface to be controlled programmatically, that is, creating workflows, triggering executions, or managing credentials. This is exactly what makes it an additional attack surface when it remains active unused. Via N8N_PUBLIC_API_DISABLED=true you disable the Public API completely, and the documentation explicitly recommends this if nobody actually uses the API. Anyone who does need the API but does not want to show the interactive documentation interface publicly can additionally set N8N_PUBLIC_API_SWAGGERUI_DISABLED=true, which only disables the API playground, while the API itself remains reachable.

• N8N_PUBLIC_API_DISABLED: Disables the entire Public API.
• N8N_PUBLIC_API_SWAGGERUI_DISABLED: Only hides the interactive Swagger interface, the API itself keeps running.

More building blocks from the security documentation

The four points named above are the ones with the greatest leverage for everyday operation, but they do not cover the full range. The n8n security documentation also covers, among other things, Single Sign-On, the requirement to verify new accounts by email, TLS encryption for the connection, the regular rotation of encryption keys, JWE decryption of OAuth 2.0 tokens, redacting execution data, securing task runners, and disabling telemetry. n8n additionally recommends regularly running a built-in security audit, which automatically checks many of these settings and lists open items. Anyone who does not want to maintain these settings themselves will find, as part of our n8n consulting support for setup and ongoing operation, where we also honestly point out where automation alone is not enough and organizational rules within the team remain necessary.

Frequently asked questions about n8n security hardening

Do I need to be able to enforce 2FA for all users?

n8n enables the feature instance-wide via N8N_MFA_ENABLED, but the actual setup happens per user account in the personal settings. A central switch that immediately makes 2FA mandatory for all accounts is not described in the core documentation, so it remains your task to require the team organizationally to activate it.

Does SSRF protection replace a firewall?

No. SSRF protection works at the application level and checks outgoing requests from workflow nodes, thereby complementing network controls such as firewalls and security groups, but according to the documentation it explicitly does not replace them.

Which nodes should I block by default?

The documentation names the Execute Command node and the Read/Write Files from Disk node as typical candidates for NODES_EXCLUDE, because both allow direct access to the underlying host system. Which other nodes are risky depends on your specific user group.

Do I even need the Public API?

Only if you control n8n programmatically, for example from your own scripts, other systems, or CI/CD pipelines. If the API is not actively used, the documentation recommends disabling it completely via N8N_PUBLIC_API_DISABLED.

Sources: n8n Security overview, Two-factor authentication, Enable SSRF protection, Blocking nodes, Disable the Public API