n8n Security Review
An n8n webhook can trigger a workflow with no authentication at all, so anyone with the URL can run it. We test webhook authentication, credential sharing, execution data and self-hosted exposure. CREST-certified testers, fixed price from £2,670 for a 2-day single-instance scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
A Webhook node’s trigger runs with no authentication unless you configure one, and that single setting decides who can reach the workflow behind it.
A workflow trusts every node inside it, so the boundary you set is the only one there is
n8n’s own Webhook node documentation lists exactly four authentication options for a trigger: Basic auth, Header auth, JWT auth, or none at all, plus a separate IP allowlist that can restrict callers by address regardless of which auth method is set. Whichever option a workflow’s author picked, or didn’t, is the only thing standing between the public internet and whatever that trigger does next, and it is set node by node rather than once for the whole instance.
Sharing in n8n works on the principle of least privilege: a credential shared with a user or a project lets them use it in their own workflows without ever seeing its underlying value, and sharing a workflow does not automatically share the credentials it depends on. All of that protection sits behind a single encryption key that n8n generates on first launch, and every worker in a queue-mode deployment has to hold an identical copy of it, so the key’s own custody matters as much as who a credential was shared with.
What a workflow leaves behind matters as much as who can trigger it. Execution data saves a node’s input and output by default, prunes automatically after 14 days or 10,000 executions, and can hold a credential value or a customer record for exactly as long as that default is left unchanged. Whether the instance is self-hosted, with the editor, the encryption key and every hardening setting in your own hands, or run on n8n Cloud instead, the same question applies: does the access on paper match the access a workflow, a credential or an installed community node actually has. It is the same ownership question we test on Power Automate flows, applied to n8n’s own nodes, credentials and projects.
SCOPE
What we review in an n8n instance
Webhook trigger authentication: none, basic, header or JWT
A Webhook node’s trigger accepts Basic auth, Header auth, JWT auth or no authentication at all, and whichever option is selected, or left unselected, decides who can invoke that URL and run the workflow behind it. The IP(s) Allowlist option can restrict callers by address, and a separate test URL exists alongside the production one for the same node, so a workflow can end up authenticated on one and not the other. We test which authentication method is actually configured against what the workflow does once triggered, and whether the test URL is still reachable once the workflow is live.
Workflow sharing and project roles
Workflows and credentials sit inside projects, and a user’s project role decides what they can do with them: an Admin can manage members and create end-user credentials, an Editor can edit and execute but cannot manage the project, and a Viewer can see everything in the project but cannot execute a workflow. Instance roles work on a separate axis again, since Owner, Admin and Member control what a user can do across the whole instance rather than inside any one project. We test whether a user’s project role and instance role actually match what they need, and whether a Viewer or Editor added to a project can reach more than that role should allow.
Saved credentials: who a shared credential is actually visible to
A credential can be shared directly with other users or shared into a project so every member can use it, and n8n applies the same rule as workflow sharing: whoever a credential is shared with can use it in their own workflows but cannot view or edit the credential’s underlying details. Sharing a workflow and sharing the credentials it depends on are two separate actions, so a shared workflow with unshared credentials leaves its nodes uneditable for whoever received it. We test what every shared credential is actually authorised for, and whether the people or projects it has been shared with still need that access.
The encryption key protecting every saved credential
Every credential n8n stores is encrypted before it reaches the database, using a key that n8n generates automatically on first launch and saves to the instance’s own settings file; set N8N_ENCRYPTION_KEY explicitly instead and every worker in a queue-mode deployment has to be given the same value or it cannot decrypt existing credentials. Losing that key without a backup makes every stored credential permanently unreadable, and n8n’s own key rotation feature is a one-way migration with no rollback path once enabled. We test how the encryption key is generated, stored and backed up, and whether it has ever been exposed outside the instance it protects.
What execution data actually saves, and for how long
Every trigger and action’s input and output data is saved to run history by default, separately configurable for successful, failed, manually launched and in-progress executions, and that setting can be overridden per workflow rather than only at the instance level. Finished executions are pruned automatically once they pass 14 days old or the total exceeds 10,000, whichever comes first, though annotated, tagged or still-running executions are exempt, and a default SQLite database does not reclaim the disk space pruning frees. We test what a saved execution actually contains for the workflows in scope, including any credential value or personal data a node’s input or output has captured.
The editor and the public API reachable from the internet
A self-hosted n8n instance’s editor and its public REST API sit on the same address unless a reverse proxy or firewall rule is put in front of them, and the public API itself can be turned off entirely if nothing in your stack actually calls it. n8n’s own hardening guidance covers SSL, SAML or OIDC single sign-on and SSRF protection to limit which hosts a workflow node can reach, none of which apply automatically on installation. We test what is reachable from outside your network without a login, and whether the public API, if enabled, is scoped to what your integrations actually need.
Instance roles and account-level security policies
An n8n instance has three built-in roles: Owner, Admin and Member, and because the Owner can see and edit every workflow, credential and project with no record of who actually created what, n8n’s own guidance is to create a separate Member account for day-to-day building rather than working as the Owner. Instance-wide policies covering multi-factor authentication enforcement, personal workspace controls and restricting sign-up to verified email addresses sit alongside those roles and have to be turned on deliberately. We test who holds Owner and Admin, whether MFA is actually enforced rather than optional, and whether a personal, unshared space is hiding a workflow or credential from the review it should have had.
Blocked nodes and file or environment access
The Execute Command node is disabled by default because it runs arbitrary shell commands, and it stays disabled only until someone removes it from the NODES_EXCLUDE list; the Code node’s access to environment variables is the opposite case, allowed by default until N8N_BLOCK_ENV_ACCESS_IN_NODE is explicitly set to restrict it. File access from nodes can be limited to specific directories with N8N_RESTRICT_FILE_ACCESS_TO, separate from the setting that already blocks reading files from the instance’s own configuration directory. We test which of these settings are actually applied against what the workflows in scope need the Code node, Execute Command node or file-handling nodes to do.
Community nodes installed from npm
Installing a community node means installing unverified code from a public npm package into your instance, and only an instance owner or admin can install or manage one, whether from the nodes panel or an environment-variable-driven install. Verified community nodes go through n8n’s own review and are barred from using runtime dependencies or touching environment variables and the file system, but an unverified node carries none of those restrictions, and community nodes can be disabled entirely with N8N_COMMUNITY_PACKAGES_ENABLED. We test what every installed community node in scope can actually reach, and whether it needed that reach to do its job.
n8n Cloud and self-hosted carry different security surfaces
n8n Cloud is fully hosted and managed, so infrastructure patching, updates and scaling are n8n’s responsibility, while a self-hosted instance puts SSL, network exposure, the encryption key and every hardening setting in your own hands instead. Feature availability shifts the same way: project roles, workflow and credential sharing, SSO and external secrets need a paid plan on either deployment, and the free self-hosted Community edition has none of them, restricting access to the instance owner and whoever created each workflow or credential. We test the instance as it is actually deployed and licensed, not the feature set a higher plan would have given it.
OUR PROCESS
n8n Security Review: From Scope to Attestation
Workflow, Trigger and Credential Mapping
We map every workflow in scope, its triggers and authentication settings, and every credential it can reach, on n8n Cloud or your self-hosted instance.
Access and Sharing Testing
We test project roles, instance roles, workflow sharing and credential sharing for gaps between who has access and who should.
Trigger, Data and Hardening Testing
We test webhook authentication directly, review execution data retention and pruning, and check environment hardening, blocked nodes, community nodes and public API exposure.
Reporting and Retest
Executive summary, technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest after remediation and an attestation letter.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST n8n pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent n8n Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 7 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test n8n For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From n8n Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our n8n instance?
At least one login for every project role and instance role in scope, plus Owner or Admin access where we’re reviewing instance-wide policies, MFA enforcement or environment variables directly. Read access to workflow definitions and the credentials list, not the credential values themselves, and on self-hosted the environment configuration, speeds up scoping but is not required to start.
Will testing touch live data?
We test read-only against production by default, and where a workflow writes, updates or deletes real records we agree a sandbox environment or specific test data with you first. Anything we create during testing to prove a finding is documented and removed afterwards.
Is this different for n8n Cloud versus a self-hosted instance?
Yes. n8n Cloud removes infrastructure, patching and network exposure from scope since n8n manages that layer, so testing focuses on your workflows, credentials, roles and projects. A self-hosted instance adds the editor’s network exposure, the encryption key, environment hardening and any blocked or enabled nodes to the same scope.
Does n8n have a customer penetration-testing policy we need to follow?
n8n publishes its own testing cadence, an annual third-party penetration test and vulnerability scans at least every 90 days, but does not publish a separate policy authorising customers to run their own tests against n8n Cloud. We confirm n8n’s current terms of service and any Cloud-specific restrictions with you before testing starts; a self-hosted instance you control does not need that sign-off.
What is out of scope?
n8n’s own Cloud infrastructure, multi-tenant hosting, and the third-party services your credentials connect to are all out of scope. We test your workflows, triggers, credentials, roles, projects and, on self-hosted, your instance configuration; a separate system on the other end of an integration is scoped and quoted as its own engagement.
How long does an n8n security review take?
A single instance with a handful of workflows sits in our 2-day single-instance scope, with more workflows, projects, community nodes or a wider integration surface extending it. We confirm the exact day count once we’ve seen the instance.
Do you need our workflow source or admin access?
No, testing is black-box by default against the role accounts you provide. Read access to exported workflow JSON, node configurations and, where relevant, community node source speeds up root-causing anything we find, and pairs well with a separate source code review.
Are your testers CREST certified?
Yes. Every n8n engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your n8n instance
An n8n webhook can trigger a workflow with no authentication at all, so anyone with the URL can run it. We test webhook authentication, credential sharing, execution data and self-hosted exposure. CREST-certified testers, fixed price from £2,670 for a 2-day single-instance scope, quoted within 24 hours.
