Security-Härtung: 2FA, SSRF-Schutz, Nodes blockieren, Public API abschalten

Wer eine selbst gehostete n8n-Instanz betreibt, trägt die Verantwortung für ihre Absicherung komplett selbst, denn n8n Cloud übernimmt einen Teil dieser Schutzmaßnahmen automatisch, ein eigener Server tut das nicht von allein. Allein im Bereich Security-Konfiguration der offiziellen n8n-Dokumentation finden sich mehr als ein Dutzend Einzelkapitel, von der Zwei-Faktor-Authentifizierung über SSRF-Schutz bis zur Public API, die in dieser Form bisher nirgends auf Deutsch gebündelt zusammengefasst wurden. Die vier wichtigsten Hebel für den laufenden Betrieb sind: 2FA verfügbar machen und einfordern, SSRF-Schutz aktivieren, riskante Nodes über NODES_EXCLUDE sperren und die Public API abschalten, wenn niemand sie braucht. Stand: Juli 2026.

Zwei-Faktor-Authentifizierung aktivieren

n8n aktiviert die 2FA-Funktion instanzweit über die Umgebungsvariable N8N_MFA_ENABLED, die standardmäßig auf true steht. Damit können einzelne Nutzer die Zwei-Faktor-Authentifizierung in ihren persönlichen Kontoeinstellungen selbst einrichten, ein zentraler Zwangsschalter für alle Konten gleichzeitig ist in der Kern-Dokumentation nicht beschrieben. Wichtig für die Praxis: Hat ein Nutzer 2FA einmal aktiviert, ignoriert n8n laut Dokumentation ein nachträgliches Deaktivieren über die Umgebungsvariable, der Schutz lässt sich also nicht versehentlich per Konfigurationsänderung wieder aushebeln.

• N8N_MFA_ENABLED: Boolean, Standardwert true, steuert ob 2FA im Nutzerkonto überhaupt verfügbar ist.
• Kein Rückweg: Einmal von einem Nutzer aktivierte 2FA bleibt bestehen, selbst wenn die Umgebungsvariable später auf false gesetzt wird.
• Organisatorische Pflicht: Da n8n die Aktivierung nicht zentral erzwingt, müssen Sie Ihr Team intern verpflichten, 2FA tatsächlich einzurichten.

SSRF-Schutz gegen Zugriffe auf interne Systeme

Server-Side Request Forgery bedeutet, dass ein Workflow-Node, etwa der HTTP-Request-Node, dazu missbraucht wird, Anfragen an interne Netzwerkressourcen, Cloud-Metadaten-Endpunkte oder Localhost-Dienste zu senden, die von außen eigentlich nicht erreichbar sein sollten. n8n bietet dafür seit Version 2.12.0 einen eigenen Schutzmechanismus, der sich über N8N_SSRF_PROTECTION_ENABLED=true aktivieren lässt. Ist der Schutz aktiv, prüft n8n ausgehende HTTP-Anfragen aus nutzergesteuerten Nodes gegen konfigurierte Allow- und Blocklisten, inklusive Weiterleitungszielen und DNS-Auflösung, um typische Umgehungstricks zu verhindern.

• Standardmäßig blockiert: Private Netzwerke wie 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16, Loopback-Adressen wie 127.0.0.0/8, Link-Local-Bereiche sowie diverse reservierte Adressräume.
• Blockliste erweitern: Über N8N_SSRF_BLOCKED_IP_RANGES lassen sich zusätzliche Bereiche ergänzen, etwa N8N_SSRF_BLOCKED_IP_RANGES=default,100.0.0.0/8.
• Ausnahmen definieren: N8N_SSRF_ALLOWED_HOSTNAMES erlaubt Hostnamen inklusive Wildcards, N8N_SSRF_ALLOWED_IP_RANGES erlaubt bestimmte IP-Bereiche, wobei die Reihenfolge Hostname-Allowlist vor IP-Allowlist vor IP-Blockliste gilt.
• Kein Ersatz für Netzwerksicherheit: Der Schutz wirkt auf Anwendungsebene und ergänzt Firewalls und Security Groups, ersetzt sie aber laut Dokumentation nicht.

Riskante Nodes mit NODES_EXCLUDE sperren

Nicht jeder Node ist für jede Nutzergruppe geeignet. Über die Umgebungsvariable NODES_EXCLUDE lässt sich eine Liste von Node-Typen definieren, die für alle Nutzer der Instanz weder auffindbar noch nutzbar sind. Der Wert wird als JSON-Array von Node-Bezeichnern übergeben, zum Beispiel NODES_EXCLUDE mit dem Inhalt ["n8n-nodes-base.executeCommand", "n8n-nodes-base.readWriteFile"]. Die Dokumentation nennt insbesondere den Execute-Command-Node und den Read/Write-Files-from-Disk-Node als typische Kandidaten für Umgebungen, in denen nicht alle Nutzer vollständig vertrauenswürdig sind, da beide direkten Zugriff auf das Host-System erlauben.

• Format: JSON-Array als String, jeder Eintrag ist der vollständige interne Node-Name.
• Effekt: Gesperrte Nodes lassen sich weder in der Nodesuche finden noch in Workflows einsetzen.
• Standardsperren aufheben: Manche Nodes wie Execute Command sind bereits werkseitig gesperrt, wer sie bewusst freigeben will, setzt NODES_EXCLUDE explizit auf ein leeres Array.

Public API abschalten, wenn sie niemand braucht

Die n8n Public REST API erlaubt es, praktisch alles, was auch über die Oberfläche geht, programmatisch zu steuern, also Workflows anlegen, Ausführungen auslösen oder Zugangsdaten verwalten. Genau das macht sie zu einer zusätzlichen Angriffsfläche, wenn sie ungenutzt aktiv bleibt. Über N8N_PUBLIC_API_DISABLED=true schalten Sie die Public API komplett ab, die Dokumentation empfiehlt dies ausdrücklich, sofern niemand die API tatsächlich nutzt. Wer die API zwar braucht, aber die interaktive Dokumentationsoberfläche nicht öffentlich zeigen möchte, kann zusätzlich N8N_PUBLIC_API_SWAGGERUI_DISABLED=true setzen und deaktiviert damit nur das API-Playground, die API selbst bleibt erreichbar.

• N8N_PUBLIC_API_DISABLED: Schaltet die komplette Public API ab.
• N8N_PUBLIC_API_SWAGGERUI_DISABLED: Blendet nur die interaktive Swagger-Oberfläche aus, die API selbst läuft weiter.

Weitere Bausteine aus der Security-Dokumentation

Die vier genannten Punkte sind die mit dem größten Hebel für den Alltag, decken aber nicht die komplette Bandbreite ab. Die n8n-Security-Dokumentation behandelt daneben unter anderem Single Sign-On, die Pflicht zur E-Mail-Verifizierung neuer Konten, TLS-Verschlüsselung für die Verbindung, die regelmäßige Rotation von Verschlüsselungsschlüsseln, die JWE-Entschlüsselung von OAuth-2.0-Tokens, das Schwärzen von Ausführungsdaten, die Absicherung von Task Runnern sowie die Deaktivierung der Telemetrie. n8n empfiehlt zusätzlich, regelmäßig einen eingebauten Security-Audit laufen zu lassen, der viele dieser Einstellungen automatisiert prüft und offene Punkte auflistet. Wer diese Einstellungen nicht selbst pflegen möchte, findet im Rahmen unserer n8n-Beratung Unterstützung bei Einrichtung und laufendem Betrieb, wir sagen dabei auch ehrlich, wo Automatisierung allein nicht reicht und organisatorische Regeln im Team nötig bleiben.

Häufige Fragen zu n8n-Security-Härtung

Muss ich 2FA für alle Nutzer erzwingen können?

n8n aktiviert die Funktion instanzweit über N8N_MFA_ENABLED, die tatsächliche Einrichtung erfolgt aber pro Nutzerkonto in den persönlichen Einstellungen. Einen zentralen Zwangsschalter, der 2FA für alle Konten sofort verpflichtend macht, beschreibt die Kern-Dokumentation nicht, deshalb bleibt es Ihre Aufgabe, das Team organisatorisch zur Aktivierung zu verpflichten.

Ersetzt der SSRF-Schutz eine Firewall?

Nein. Der SSRF-Schutz arbeitet auf Anwendungsebene und prüft ausgehende Anfragen aus Workflow-Nodes, er ergänzt damit Netzwerkkontrollen wie Firewalls und Security Groups, ersetzt sie laut Dokumentation aber ausdrücklich nicht.

Welche Nodes sollte ich standardmäßig blockieren?

Die Dokumentation nennt den Execute-Command-Node und den Read/Write-Files-from-Disk-Node als typische Kandidaten für NODES_EXCLUDE, weil beide direkten Zugriff auf das zugrunde liegende Host-System erlauben. Welche weiteren Nodes riskant sind, hängt von Ihrer konkreten Nutzergruppe ab.

Brauche ich die Public API überhaupt?

Nur wenn Sie n8n programmatisch ansteuern, etwa aus eigenen Skripten, anderen Systemen oder CI/CD-Pipelines heraus. Wird die API nicht aktiv genutzt, empfiehlt die Dokumentation, sie über N8N_PUBLIC_API_DISABLED komplett abzuschalten.

Quellen: n8n Security-Übersicht, Zwei-Faktor-Authentifizierung, SSRF-Schutz aktivieren, Nodes blockieren, Public API deaktivieren