Which Dify credentials expose apps, and why exposure matters
Every Dify app you connect to a product, pipeline or another agent is opened by a credential, and the credential type decides who can call the app and how quickly you can cut that access. Three kinds matter here. A service API key authenticates a calling system to an app's API. A published MCP server URL exposes the app to MCP clients, and in this setup the credential travels inside the address itself, so anyone who copies the URL holds the access. A web app token in embed code lets a page load a published web app. Each one is a bearer secret: whoever holds it can use it until it is changed or revoked, and none of them needs a user login to work.
The Community and Enterprise editions differ mainly in who manages these credentials. Community is limited to a single workspace, so one group of administrators controls every app key in the instance. The review list is short, but any leak reaches the whole instance. Enterprise adds multiple workspaces and SSO with separate scopes for workspace access and web app access, which lets you separate who signs in to the console from who may use published apps. Neither edition removes the need to confirm in the Dify app management docs who may create, view and regenerate each credential type in your version.
Dify DSL exports include app configuration, workflow nodes, model parameters, prompts and knowledge base connections, but they exclude third-party API keys, knowledge base content and usage logs. A DSL file is therefore reasonable to share for review, but importing it into another instance is still a credential event, because model and tool keys must be entered again by someone accountable for them. Confirm whether service API keys and embed tokens are carried in an export before you rely on that. Before any regeneration, list every system that calls each key or embeds each token, so you can update all consumers at the same time.
Credential types and when each fits
This table compares the three credentials that let outside callers reach a Dify app, by where each is used, who holds it, how far it reaches and the first steps after exposure. Read each row as a question to check against your Dify version, because console labels and regeneration behavior change between releases. The main takeaway is that an MCP server URL carries its credential inside the address, so treat it as a secret wherever it is pasted.
| Credential | Where it is used and how far it reaches | Who holds it | First steps on exposure |
|---|---|---|---|
| Service API key | Server-side calls from your backend to one Dify app's API | Backend team and the service that keeps it in its secret store | Regenerate, then update every caller. Confirm whether the old key stops working immediately. |
| MCP server URL | Clients that connect to a published Dify app as an MCP server | Anyone who copies the URL, including people with access to client config files | Treat the URL as a secret. Regenerate it and reconnect every approved client. |
| Web app embed token | Browser-side access to a published web app embedded in a page or portal | Every visitor's browser, so the value can be read from the page source | Assume it is public. Restrict who can embed the app and confirm how to invalidate it for your version. |
| Model provider keys | Dify calls to model providers and plugins on behalf of your apps | Workspace administrators, stored inside Dify | Rotate the key at the provider, then update the stored credential in Dify. App exports exclude these keys. |
| Expiry and scope | Whether each credential expires, is limited to one app or is limited by permission | Administrators, who should record the answers for their version | Confirm each answer in the Dify docs for your version before the app goes live. |
How these credentials leak in practice
The most common leak is a service API key pasted somewhere it was never meant to live: a .env file or script committed to a source repository, a CI job that echoes its configuration into build logs, or a notebook shared with a vendor. Dify service API keys are issued per app and act as the app's credential, so anyone holding one can call the app's endpoints. Verify this in your own environment by running a secret scanner over the repositories and CI logs that touch Dify, and by checking whether your pipelines pass the key as a plain variable or from a secrets store. Confirm with your platform team which store holds these keys and who can read it.
A second path is the MCP server URL. Published MCP endpoints can embed credentials in the address itself, so the full URL becomes the secret. These URLs are easy to copy into a chat thread, a ticket or a wiki page while someone troubleshoots a client connection, and they look harmless because they are not labeled as keys. Embed code for web apps is a similar risk when it is pasted into a public page or a shared template, because the token travels with the page source. Review where published URLs and embed snippets have been shared, and treat any copy outside the owning team as exposed until you have checked it.
Exports and departures create the slow leaks. A DSL export shares app configuration, prompts and workflow structure between teams, and the Dify docs state that exports do not include third-party API keys, so the file is less sensitive than a key but still reveals internal logic that attackers and competitors value. Contractors who built apps may still hold console accounts, service keys or copies of MCP URLs after their engagement ends. Ask for a register of who created or received each app credential, and make offboarding for external builders a checklist item that includes rotating any key they could have seen.
How to inventory and lock down app credentials
This sequence gives you a current register of every Dify app that hands out credentials, a named owner for each consuming system, and credentials stored where only approved people and systems can reach them. The result is a workspace where every key and URL in circulation can be traced, justified and revoked.
List every app and its published access points
Open the Studio in each workspace and list every app, including drafts that have been published. For each app, record whether it exposes a service API, a web app with a shareable link, an embedded web app, or a published MCP server URL. Open the API Access or publish settings for each app to confirm what is live, since an app can be published in one mode and still hold a service API key from earlier work. The step is done when the register covers every app in every workspace you own and nothing is marked as unknown.
Record the consuming system and owner for each credential
For every service API key and MCP URL in the register, name the system that uses it, the team that owns that system, and the person who approved the exposure. Ask each owner to confirm that the system still calls the app and that the caller is expected. Credentials with no confirmed consumer are candidates for revocation. The step is done when each row has an owner and a consumer, and any row without one has been reviewed and either assigned or scheduled for removal.
Move keys out of code, tickets and shared notes
Search source repositories, CI variables, configuration files, chat threads, tickets and wiki pages for Dify API keys and MCP URLs that embed credentials. Replace each copy with a reference to a secrets manager that your organization already operates, and inject the value into the consuming service at runtime. Where a key has already been pasted into a ticket or chat, treat it as exposed and move to the regeneration step for that app. The step is done when your code search returns no live credentials and each consuming system reads its value from the secrets manager.
Restrict who can create and view keys
Review the workspace member roles in the console and identify which accounts can open app API settings, create service API keys and copy them. Limit that permission to the platform or app owners who need it, and keep editing rights for prompts and workflows separate where your role model allows. Check whether shared team accounts or long-lived invitations exist, since these make key ownership unclear. Confirm the result by signing in as a member without the permission and verifying that the key view and create actions are unavailable. The step is done when a test account without the permission cannot display or create a key.
Confirm MCP URLs and embed code are published only where intended
For each MCP server URL, check which clients have been given it and whether the URL carries a credential that a client, log or browser history could capture. For each embedded web app, review the pages and domains where the embed code appears. Remove the embed from any page that should not expose the app. Then send a test request to the MCP endpoint and to the embedded app from a network location that should not have access, and confirm that the request is refused or that the app requires the intended sign-in. The step is done when every published location is on the approved list and the unauthorized test fails.
Regenerate exposed credentials and retest
For every credential that was found in code, tickets, logs or unintended pages, generate a new service API key in the app settings, update the consuming system from the secrets manager, and then delete the old key. Repeat the step for any MCP URL that carried a credential. Send a request with the old key and confirm it is rejected, then send a request with the new key and confirm the consuming system still works. Ask the consuming owner to confirm the change before closing the ticket. The step is done when every replaced credential fails with the old value and succeeds with the new one.
Repeat the register review on a fixed schedule
Set a recurring review of the register so that new apps, new keys and new MCP or embed locations are added and retired records are removed. Ask the platform owner to confirm the review interval your policy requires. Compare the console state with the register each time, and check that the access list has not grown beyond the approved owners. Because Dify minor releases arrive roughly monthly, include a check of the release notes for changes to API authentication. The step is done when the review produces a signed record showing no unregistered credentials.
Controls that reduce exposure risk
A leaked Dify credential is only as damaging as what it can reach. The controls below work together: they narrow which key or URL exists for each consumer, who can create them, where they are stored, how their use is watched, and where the Dify API sits on the network. Review each one against your own deployment before you publish an app.
Separate keys per consumer
Issue a distinct service API key for each application, backend or pipeline that calls a Dify app, rather than sharing one key across several systems. When a key is shared, revoking it stops every consumer at once, and you cannot tell from the logs which system made a call. Keep a written inventory that maps each key to its owner, its app and its environment, so a rotation touches one consumer at a time.
Least-privilege workspace roles
Anyone who can open an app's API or publish settings can usually reveal or regenerate the credentials that open it. Limit editor and admin roles to the people who build and publish apps, and give read-only or operator roles to people who only monitor them. Review workspace membership on a fixed schedule and remove accounts for people who have left the project, since their access persists until someone changes it.
Store credentials in a secrets manager
Keep service API keys and the MCP server URLs that embed credentials out of prompts, workflow notes, shared documents, chat threads and exported DSL files. The DSL export does not carry third-party API keys, but consuming systems often store the Dify key in plain configuration. Place each key in a secrets manager your organization already operates, inject it at runtime, and confirm that CI logs and application error traces do not print it.
Log and review API usage
Track which keys call which apps, from which source addresses, and at what volume. Compare call patterns against the consumers in your inventory, since a key used from an unexpected network or at an unusual hour is a sign of exposure. Confirm with your Dify version which usage and monitoring data the console and the API expose, and forward Nginx and API access logs to your central logging system so reviews do not depend on the console alone.
Network placement of the API and Nginx
The Docker Compose deployment places the Dify API behind Nginx. Expose only the Nginx entry point to the networks that need it, keep the api, worker and database services on internal networks, and terminate TLS at that entry point. A key sent in plaintext over an open network or reached directly through an internal port bypasses controls you set elsewhere. Test reachability from outside your allowed networks after every change to the Compose file or the proxy configuration.
Keep sandbox and proxy scope narrow
A credential is more valuable when the platform can make outbound calls on its behalf. Keep the SSRF_PROXY path enabled so HTTP nodes and tools cannot reach internal and private address ranges, and avoid broad allowlists that would let a workflow forward a key to an internal system. Do not change SECRET_KEY as a credential fix, because changing it logs out all users, and rotate it only in a planned window. Confirm the sandbox API key is not the default value before go-live.
Regenerating credentials after an exposure
When a service API key or a published MCP server URL leaks, the first move is to revoke or regenerate the exposed credential in the Dify app that issued it, so the leaked value stops working before anything else changes. Regenerating an app credential replaces only that one secret. Plan the replacement before you start: list every system that calls the app, every MCP client that connects to its server URL, and every embed page that carries a web app token, and note who owns each one. Then update those consumers in a planned order, starting with the systems that carry the most traffic or the most sensitive data, and confirm each one works with the new value before moving to the next.
After the swap, check each consumer for failures. A caller still using the old key will receive authentication errors, and an MCP client still pointed at the old URL will fail to connect. Treat those errors as the list of places you missed. Next, review the usage logs for the app over the exposure window, from the time the credential could first have been seen to the time it was revoked. Look for request volume that does not match normal traffic, unfamiliar source addresses, and calls to tools or workflow steps that the owning team did not expect. The Dify app management documentation at Dify docs: App management is the natural next read for locating the credential and log views in your version, and you should confirm those screens against the release you run.
Record the incident with the exposed credential's identifier, the exposure window, the systems updated, the consumers that failed and were fixed, and the findings from the log review. Do not treat SECRET_KEY rotation as a substitute for this sequence. SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users, so it is an instance-wide operation that needs a planned window and does not revoke a leaked app key. Use it only when the instance secret itself may be compromised, and confirm the effect on plugin credentials and OAuth connections before you change it.
Limits to confirm in your environment
The controls for API keys, MCP server URLs and embed tokens differ between Dify versions and editions, and the console screens move with the 1.x release line. Treat each item below as a question to answer on your own instance, with the exact version you run, before you write a rotation or revocation procedure around it.
Console paths for keys
The menu location for creating and revoking a service API key depends on the app type and on the console version you run. Record the exact clicks on your version, including where the key list sits, whether revocation is a delete or a disable action, and whether a revoked key stops working immediately or after a cache window. Write these steps down in your runbook rather than relying on screenshots from documentation written for another release. The app management docs are the starting point, but confirm each step in your own console.
MCP URL rotation
Confirm whether a published MCP server URL can be regenerated without changing the underlying app. If the URL embeds a credential, rotation may be possible only by unpublishing and republishing, which changes the endpoint every connected MCP client uses. Ask the question for your version and write down the consequence: which client configurations must be updated, in what order, and whether any client caches the old address. This determines whether exposure of an MCP URL is a configuration change or an outage.
Individual embed token revocation
Web app tokens in embed code may or may not be revocable one at a time. Check whether revoking a token affects only one embedding site or every embed of the same app, and whether the console shows which token belongs to which page. If revocation is all or nothing, a leak on one site forces a change on every site that embeds the app. Test this on a non-production app before you publish a policy that depends on it.
Audit logs by edition
Find out which records of key creation, key use, MCP URL changes and token revocation your edition keeps, how long they stay, and whether you can export them. Community and Enterprise editions may differ, and the Enterprise tier is priced separately, so confirm this with the vendor against your required retention before you assume an investigation trail exists. Without these records, you cannot tell whether an exposed credential was used.
Change pace across 1.x
Minor releases in the 1.x line arrive roughly monthly, and console screens, key behaviors and MCP options can change between them. Pin the version you tested your runbook against, read the release notes before each upgrade, and repeat the console checks after every move. A procedure verified on one release is a hypothesis on the next until you have rerun it.
Questions teams ask before hiring help with Dify credentials
Can our internal team rotate Dify API keys and MCP URLs on its own?
Yes, most teams can do the core rotation themselves, because regenerating a service API key or an MCP server URL is a console action in the app. The harder part is finding every consumer that holds the old value. Your team can do it alone if it has a current inventory of apps, the systems that call them, and an owner for each integration. Without that inventory, the work usually stalls at the first system nobody remembers. Confirm the current regeneration behavior for your Dify version in the app management docs before you plan the window.
What drives the cost of help with Dify credential exposure?
Cost follows the amount of work, not a fixed package. The main drivers are the number of apps that expose a service API key, MCP server URL or web app embed, the number of consuming systems that hold those values, whether your team already runs a secrets manager, and whether a review of past exposure is needed. Each driver can be one-time (inventory, rotation, verification) or recurring (periodic review). Ask any provider for a quote built from a written scope that lists each app and consumer, the rotation steps, and what is delivered at the end.
How long does a credential exposure review and rotation take?
Duration depends on how many apps and consumers are involved and how many teams must coordinate a cutover. A small set of apps with clear owners is a short exercise, while many apps spread across several teams needs a planned change window and sign-off from each owner. Dify does not publish a duration for this work, so treat any estimate you receive as something to confirm against your own inventory. Ask for a timeline in the written scope with the dependencies named.
What do we need to provide before work starts?
Plan to provide access and information rather than configuration decisions alone:
- A list of Dify workspaces and apps, with the owner of each app
- Read access to the console or an export of app settings, so exposed credentials can be identified
- A list of consuming systems, such as backends, MCP clients, embedding pages and automation jobs, with their owners
- Your secrets tooling and the places where credentials are stored today
- Change windows and a contact for each consuming team
The scope should state which of these you own and which the provider needs.
Do we need an incident review, or is rotation enough?
Rotation stops a leaked value from working again, but it does not show whether it was used. An incident review is needed when a key or MCP URL may have been public for a meaningful period, appeared in a repository, log, or shared page, or was embedded in a client-side page. The review looks at the request logs and the consuming systems to judge what was accessed. Whether logs cover that period depends on your logging setup, so confirm retention before you start. Involve your security or legal team if the review finds access you cannot explain.
Does rotating an API key or MCP URL affect other Dify settings?
Rotating a service API key or an MCP server URL affects only the callers that use that value, but those callers fail until they are updated. Changing SECRET_KEY is a different operation, since it logs out all users and affects OAuth credentials, so it needs its own planned window. Confirm in the environment variable reference which settings are affected by any change you make. Test each consuming system after cutover, not only the Dify console.
How do we keep exposed credentials from coming back?
The lasting fix is a process, not a single rotation. Store credentials in your secrets manager, avoid pasting them into prompts, workflow nodes, embed code, or shared documents, and review new MCP server URLs and web app tokens before publishing. Assign an owner to each app and set a recurring review of the consuming systems. Keep the Dify release notes in view as well, since security changes to API authentication arrive in minor releases. Ask any provider to document these controls as part of the handover.
How DeployOpen scopes credential hardening for Dify
DeployOpen scopes credential hardening for Dify in writing before any change is made, starting with an inventory of every app, workspace and consumer that relies on a service API key, a published MCP server URL or a web app embed. The inventory records who holds each credential, which systems call it, where it is stored (env files, secrets managers, CI variables, product configuration) and whether the app is reachable from outside your network. Without that map, regeneration after an exposure tends to break callers that nobody knew about, so this step decides how much change the rest of the work can safely make.
Control design follows the inventory and stays inside your infrastructure. DeployOpen plans the regeneration procedure for each credential type, the storage pattern your secrets tooling supports, the logging and review you need to spot unexpected use, and the callers that must be updated in the same window. Your secrets tooling and your change windows set the sequence and the scope, because rotating an MCP URL or a service API key touches client applications that your own teams or other vendors may own. Implementation and verification then run against the written scope, with each rotated credential tested from the consumer side and the old value confirmed as rejected. Ask whether your secrets platform, change calendar and application owners will be available during the agreed window.
Ongoing support is optional. Upgrades to Dify can change how keys and MCP endpoints behave, and new apps appear as teams adopt the platform, so a retainer can cover periodic re-inventory, credential review, and testing after each upgrade. Quotes follow the written scope, so ask for the inventory, control design, implementation and verification phases to be priced separately, and state which application owners and secrets administrators are expected to take part.
