Skip to main content

n8n security

Self-hosted n8n is a high-value target: it stores credentials to other systems and can exfiltrate data via HTTP nodes. Apply defense in depth.

Authentication and access​

  • Do not leave the editor on 0.0.0.0:5678 on the public internet without auth + TLS.
  • Use your identity stack where possible: VPN, SSO in front of the proxy, or n8n’s enterprise/auth options appropriate to your edition—verify current docs for your version.
  • Basic auth env vars are sometimes used for a coarse gate (N8N_BASIC_AUTH_* where supported)—treat as a supplement, not a full IAM system.

Secrets management​

  • Store integration secrets in n8n Credentials, not hard-coded in workflows.
  • Protect N8N_ENCRYPTION_KEY like any root secret; rotate with a tested procedure (config).
  • Prefer secret files or orchestrator secret injection over plaintext in compose files (configuration methods).

Network​

  • Firewall outbound from n8n if workflows should not reach arbitrary hosts.
  • Webhook URLs — Understand that anyone who can hit a webhook URL may trigger logic—use secrets in the path, HMAC validation, or network allowlists where integrations support them.
  • Public API — N8N_PUBLIC_API_DISABLED can disable the REST API surface if unused (deployment variables).

Hardening checklist​

ControlNotes
TLSTerminate at proxy; consistent https URLs
Editor exposureRestrict by network or SSO
BackupsDB + encryption key + volume
UpdatesTrack stable releases; test upgrades
Least privilegeSeparate service accounts per integration
AuditWho can import workflows or add credentials?

Workflow safety​

  • Review imports — Community workflows are code; inspect nodes and expressions.
  • Limit expressive nodes in multi-tenant contexts if your edition supports restrictions.
  • Treat any HTTP node as potential server-side SSRF unless outbound access is constrained (allowlists, egress firewalls).