n8n-MCP beveiligen (security hardening)
Gebaseerd op czlonkowski/n8n-mcp @ f895e5e, licentie MIT
Dit bestand is door ToolBrain vertaald en inhoudelijk gewijzigd op 2026-08-30, op basis van
"Security & Hardening" uit czlonkowski/n8n-mcp (MIT), zie
https://github.com/czlonkowski/n8n-mcp/blob/f895e5ecc732aed31e2ca9748027034f5b19cccd/docs/SECURITY_HARDENING.md
en ../LICENSES/n8n-mcp-MIT.txt.
Het belangrijkste om te begrijpen voordat je n8n-MCP inzet: n8n-mcp is puur een doorgeefluik naar de reguliere n8n REST-API. De echte beveiligingsgrens ligt bij n8n zelf, niet bij n8n-mcp. Alles wat via n8n-mcp mogelijk is, kan ook rechtstreeks via de n8n REST-API met dezelfde API-key — n8n-mcp geeft geen enkele extra bevoegdheid boven wat die n8n-API-key al toestaat.
Concreet betekent dit: wie toegang heeft tot de MCP-sessie, heeft effectief dezelfde rechten als
de geconfigureerde N8N_API_KEY. Beveiligingsmaatregelen moeten dus in de eerste plaats op die
API-key en op n8n zelf gericht zijn, niet alleen op de MCP-laag ervoor.
Hardening-opties
| Omgevingsvariabele | Doel | Voorbeeld |
|---|---|---|
AUTH_TOKEN | Verplicht in HTTP-modus. Gebruik een sterke, willekeurige waarde (min. 32 tekens). | openssl rand -base64 32 |
DISABLED_TOOLS | Kommagescheiden lijst van MCP-tools die je wilt uitschakelen. | n8n_create_workflow,n8n_test_workflow |
WEBHOOK_SECURITY_MODE | SSRF-bescherming voor webhook-trigger-URL's, de n8n-API-client (N8N_API_URL) en per-request-URL's uit de x-n8n-url-header. Standaard (strict) blokkeert localhost, private (RFC1918) netwerken, overige niet-publiek-routeerbare IANA-ranges (waaronder het 100.64.0.0/10-shared-address-space, multicast en broadcast) en cloud-metadata-endpoints. moderate staat localhost toe (bijv. http://localhost:5678) maar blokkeert de rest nog steeds. permissive staat alles behalve metadata toe — alleen geschikt wanneer n8n-mcp en n8n op hetzelfde private Docker/Kubernetes-netwerk draaien, of wanneer je n8n-instantie alleen bereikbaar is via een CGNAT-overlay zoals Tailscale. Cloud-metadata-endpoints (169.254.169.254, metadata.google.internal, etc.) blijven in alle modi geblokkeerd. | moderate |
Workflowmogelijkheden beperken
De workflowbeheer-tools kunnen workflows aanmaken én uitvoeren op je n8n-instantie, inclusief workflows met Code-nodes. Dat is bewuste functionaliteit — Code-nodes zijn een volwaardig n8n-onderdeel. Wil je sturen wat een Code-node mag doen, dan regel je dat op je n8n-instantie zelf, niet in n8n-mcp:
- Code node sandbox: staat standaard aan in n8n en beperkt wat een Code-node kan uitvoeren
N8N_CODE_NODE_ALLOWED_MODULES: bepaalt welke Node.js-modules een Code-node mag importeren- RBAC (n8n Enterprise): fijnmazige toegangscontrole per gebruiker of rol
Heb je workflow-creatie via MCP helemaal niet nodig, schakel de tools dan volledig uit:
DISABLED_TOOLS=n8n_create_workflow,n8n_update_full_workflow,n8n_update_partial_workflow,n8n_test_workflowLet op prompt injection
Alles wat n8n-mcp uit een n8n-instantie teruggeeft — workflownamen, beschrijvingen, executieresultaten — wordt aan het taalmodel getoond. Heeft iemand met kwade bedoelingen toegang om workflows op diezelfde n8n-instantie aan te passen, dan kan die persoon een workflownaam of -beschrijving zo opstellen dat die de AI-assistent probeert te manipuleren.
Dit is geen n8n-mcp-specifiek risico, maar een algemeen kenmerk van elk LLM-agent-systeem dat door gebruikers aangemaakte content aan het model voorschotelt. Beperkende maatregelen:
- Beperk wie workflows mag aanmaken of wijzigen op de n8n-instantie
- Gebruik
DISABLED_TOOLSom het aantal beschikbare MCP-tools te beperken - Controleer AI-gegenereerde workflowacties voordat ze daadwerkelijk worden uitgevoerd
Praktijkvoorbeeld (NL)
Een Nederlands ICT-dienstverlener beheert voor meerdere MKB-klanten losse n8n-instanties en wil
één centrale n8n-mcp-server inzetten zodat het eigen supportteam via Claude sneller storingen kan
onderzoeken. Omdat de n8n-API-key voor elke klantinstantie volledige rechten geeft (workflows
aanmaken, wijzigen én uitvoeren), realiseert de teamleider zich dat een lek van de MCP-sessie
net zo erg is als een lek van die API-key zelf. Ze besluiten daarom DISABLED_TOOLS te zetten
op alle schrijvende workflow-tools voor het supportteam — alleen lezen en valideren blijft aan
staan — en geven alleen de twee senior engineers die ook daadwerkelijk workflows mogen aanpassen
een aparte, minder beperkte MCP-configuratie. Zo blijft het gros van het team veilig binnen een
read-only werkwijze, zonder dat de flexibiliteit voor de mensen die het echt nodig hebben
verdwijnt.