Dify Application Security Review
A published Dify app carries the workspace’s model and tool credentials with it. We test who can reach that app, what its workflow nodes can do, and how self-hosted instances are exposed. CREST-certified testers, fixed price from £6,000 for a 5-day single-application 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.”
Dify workspaces run on four built-in roles, and only the Owner and Admins can add members or manage the model provider keys that every app in the workspace shares.
Every app in a Dify workspace shares the same model and tool credentials, so app access is the only boundary that exists
Dify’s own workspace documentation lists four built-in roles: an Owner with full control of the workspace, an Admin who manages members and model providers on top of everything an Editor can do, an Editor who can create, edit and delete apps and knowledge bases, and a Normal member who can only use apps that are already published. Owner, Admin and Editor can all create a new knowledge base, but who can actually see and query an existing one is set separately in that knowledge base’s own permissions setting, so the role that let someone build a knowledge base is not the authorisation that decides who can retrieve from it afterwards.
Every model provider’s API key is set once, grants model access to every app in the workspace, bills usage directly to that provider’s account, and can only be added or changed by the Owner or an Admin. Tool credentials for a service such as Google or GitHub work the same way: authorised once at workspace level, or inside the specific app or node that calls it, and from then on any workflow, chatflow or agent in the workspace can use that credential to reach the service behind it. That is the mechanism behind OWASP’s Excessive Agency category: an injected prompt in a retrieved document, a fetched web page or a user message does not need its own credentials to misuse a tool, it only needs an agent that is willing to call one that is already authorised.
A workflow’s Code node runs Python or JavaScript inside a dedicated sandbox container, isolated from the host and the rest of the stack, and the HTTP Request node’s outbound calls are routed through an SSRF proxy that blocks requests to internal and private IP ranges by default. None of that protects the self-hosted installer itself: the /install page that creates the first admin account has no password gate unless you set INIT_PASSWORD before first launch, so whoever reaches that page first owns the workspace. Dify Cloud removes that installer and the sandbox’s own configuration from scope entirely, in the same way n8n Cloud removes an n8n instance’s network exposure from scope, leaving the workspace’s roles, credentials and published apps as the surface either way.
SCOPE
What we review in a Dify application
Workspace roles and what each one can actually do
Dify workspaces run on four built-in roles, Owner, Admin, Editor and Normal, and only the Owner and Admins can add new members or manage the model providers every app in the workspace draws on. We test who holds Owner and Admin, whether a Normal member can reach more than a published app, and whether the roles assigned on paper match what each account can actually do in the console.
Published web apps: public or behind a login
Every Dify app can be published as its own web app, and Dify’s own publishing guidance is to decide up front whether that app should be public or require authentication before you share the link. We test what a published app’s web interface, embed or shared link actually exposes without a login, and whether a form field, an uploaded file or a conversation opener returns more than the app was scoped to answer.
Knowledge base permissions and what retrieval returns
A knowledge base’s own permissions setting decides which workspace members can access it, separately from who could create it, and that same access governs what an app’s retrieval step is able to pull back at query time. We test whether a knowledge base’s permissions match the sensitivity of what it holds, and whether an app connected to it can retrieve chunks a user querying it should not see.
Model provider API keys and who can add one
A model provider’s API key is entered once, grants every app in the workspace access to that provider’s models, and bills usage directly to the account behind the key, with only the Owner and Admins able to add or rotate one. We test which provider keys are configured, whether workspace access to add a key is limited to the roles that need it, and what happens to app access if a key is revoked or a provider account changes.
Tool and MCP server credentials shared across apps
Tool plugins such as Google or GitHub, and any MCP server you connect, are authorised either at workspace level or inside the specific app or node that calls them, and once authorised any workflow, chatflow or agent in the workspace can call that tool with the same credential. We test which tools and MCP servers are authorised, at what scope, and whether an app that never needed a given tool can still reach it, the same credential-sharing question we test on an n8n instance’s shared credentials.
The Code node’s sandbox and what it can reach
The Code node runs custom Python or JavaScript inside a dedicated sandbox container, separate from the host and the rest of the Dify stack, with its worker timeout, network access and output size controlled by the sandbox’s own environment variables. We test what a workflow’s Code node can actually reach from inside that sandbox, and whether its output limits or network restrictions have been left at default for a workflow that needs more than that.
HTTP Request node calls and SSRF protection
Every outbound HTTP Request node call, and every image Dify downloads, is routed through an SSRF proxy that blocks requests to internal and private IP ranges by default, with response size, timeout and SSL verification each capped by their own environment variable. We test what a workflow’s HTTP Request nodes actually call, whether the SSRF proxy is still in place in your deployment, and whether a raised timeout or size limit has widened what a node can pull back.
Application and knowledge base API keys
Publishing an app for programmatic access issues its own app API key, and knowledge bases have a separate API key again, both authenticated as a bearer token that Dify’s own documentation says to keep server-side and never embed in client code. We test how these keys are issued, stored and rotated, and whether a key meant to stay server-side has ended up reachable from a browser, a mobile client or a public repository.
Prompt injection into tool use and workflow actions
A prompt hidden in a retrieved document, a scraped web page or a user message does not need its own credentials to misuse a workspace’s tools, and OWASP’s Top 10 for LLM Applications lists exactly this path under Prompt Injection and Excessive Agency: the injection persuades an already-authorised agent to act. We test whether an injected instruction inside content your app processes can trigger a tool call, a workflow branch or a knowledge base write the original user never asked for.
Self-hosted installer exposure versus Dify Cloud
A self-hosted instance’s /install page, which creates the first admin account, has no password gate unless INIT_PASSWORD is set before first launch, and the sandbox, database and every other service in the Docker Compose stack sit on your own infrastructure rather than Dify’s. Dify Cloud removes the installer, the sandbox’s configuration and the underlying infrastructure from scope entirely, leaving workspace roles, credentials and published apps as the surface either way. We test the instance as it is actually deployed, not the isolation a managed plan would have provided.
OUR PROCESS
Dify Application Security Review: From Scope to Attestation
Workspace, Role and Credential Mapping
We map every workspace role, model provider key, tool and MCP server credential, and knowledge base permission in scope, on Dify Cloud or your self-hosted instance.
App and Access Testing
We test published web apps, embeds and API keys for what they expose without a login, and whether workspace roles match the access each account actually has.
Workflow, Node and Injection Testing
We test Code node sandbox boundaries, HTTP Request node SSRF protection, knowledge base retrieval and prompt injection paths into tool use directly.
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 Dify 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 Dify Application Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
Depends on AI system complexity
Single LLM-powered chatbot, basic RAG (≤100 documents), no agent tools. Around 5 to 7 working days from kickoff to report.
Get a fixed quoteDepends on AI system complexity
Multi-tool agent system, complex RAG pipeline, fine-tuned model, multi-tenant. Around 8 to 12 working days from kickoff to report.
Get a fixed quoteDepends on AI system complexity
Production AI platform, multi-agent orchestration, regulated AI use case (FCA, NHS), custom-trained models. Around 12 to 18 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Dify 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 Dify Application 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 Dify app?
At minimum a Normal-role login to the published app, plus Editor access to the workflow, knowledge base and tool configuration behind it, and Owner or Admin access where we are reviewing model provider keys, workspace roles or self-hosted environment configuration directly. Read access to exported workflow DSL and the knowledge base’s document list 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 to a knowledge base, calls a paid tool or triggers an external action, we agree a sandbox environment or specific test data with you first. Anything we create to prove a finding, such as a test document or a triggered workflow run, is documented and removed afterwards.
Is this different for Dify Cloud versus a self-hosted instance?
Yes. Dify Cloud manages the installer, the sandbox and the underlying infrastructure, so testing focuses on workspace roles, credentials, knowledge bases, workflows and published apps. A self-hosted instance adds the /install page, environment secrets, the sandbox’s own configuration and network exposure of the console itself to the same scope.
Does Dify have a customer penetration-testing policy we need to follow?
Dify’s published security policy covers reporting a vulnerability in the Dify product itself through GitHub Security Advisories rather than authorising customer testing against Dify Cloud. We confirm Dify’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?
Dify’s own Cloud infrastructure, multi-tenant hosting and the third-party services your model provider or tool credentials connect to are all out of scope. We test your workspace, apps, workflows and knowledge bases and, on self-hosted, your instance configuration; a separate system on the other end of a tool integration is scoped and quoted as its own engagement.
How long does a Dify application security review take?
A single application with its workflows, knowledge base and connected tools sits in our 5-day single-application scope, with additional apps, a wider agent or MCP surface, or a larger knowledge base extending it. We confirm the exact day count once we have seen the workspace.
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 DSL, node configurations and, where relevant, custom tool or MCP server source speeds up root-causing anything we find, and pairs well with a separate source code review.
Are your testers CREST certified?
Yes. Every Dify 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 Dify application
A published Dify app carries the workspace’s model and tool credentials with it. We test who can reach that app, what its workflow nodes can do, and how self-hosted instances are exposed. CREST-certified testers, fixed price from £6,000 for a 5-day single-application scope, quoted within 24 hours.
