Dify API keys: resource scope is narrower than workspace trust
Dify combines applications, datasets, model providers, tools, and workspace collaboration. Its API keys are easy to create and easy to paste into an integration. The security question is what each key is allowed to reach after it authenticates. Dify's current code and documentation distinguish application API keys, dataset API keys, and workspace roles, while model-provider credentials may be shared across the workspace.
The resource boundary is the first useful control. An application API key should not be treated as a workspace administrator credential. A dataset key should be scoped to the knowledge resources it needs. A user's workspace role affects who can view, create, or delete those resources.
Understand the key type before deployment
Application keys are associated with an application and are intended for calls to that application's service API. Dataset keys are associated with knowledge or dataset operations. Dify's console API code shows permission checks for key creation and deletion, with role and resource-level RBAC checks. That does not mean every key has the same privileges. The resource identifier and the role on that resource both matter.
Record the key type, resource ID, owner, creation time, and purpose. Do not label every Dify key as “workspace API key” in a secret inventory. A response that shows masked keys does not remove the need to protect the underlying value.
If the deployment uses personal access tokens or account sessions, keep them separate from application keys. A short-lived user session should not be converted into a permanent integration secret without a deliberate design.
Model-provider credentials have a wider blast radius
Provider API keys added to a Dify workspace can be used across applications that select that provider. A user who can change a model provider may affect cost, data flow, availability, and the destination of prompts or retrieved content. Review who can manage model providers and which applications can use each one.
Use provider keys with the narrowest project and spending limits available. Separate production and development workspaces where practical. Rotate a provider key after a suspected Dify compromise and check the provider's usage history for unexpected calls.
Dify applications may call external tools or retrieve data from knowledge bases. A key is not the only outbound path. Review tool credentials, webhook URLs, and dataset permissions as separate trust relationships.
Review roles and resource ownership
Map workspace owners, admins, editors, and other roles to the actions they can perform. Test a non-admin user against application-key creation, dataset-key creation, model-provider changes, and workspace settings. A UI element that is hidden but still callable by the API is a permission bug or an expected role behavior that needs to be documented.
Dataset keys may be read-only or limited to a particular dataset, depending on the deployment and key flow. Verify the actual behavior in the installed version rather than relying on an old screenshot. Remove keys for deleted applications and datasets.
Review the application publication settings. A public web app, an API endpoint, and an internal workflow can have different user authentication requirements. A publicly reachable application should not inherit a privileged tool credential merely because it is convenient.
Measurement
ZoomEye can find assets that identify as Dify. The count is a discovery signal, not evidence that an application key or provider credential is exposed.
On 2026-11-11, a count-only query with dork app="Dify", sub_type=all, page 1, and page size 1 returned 12,968 matching assets. The deterministic search link is the Dify ZoomEye query. The result describes matching product assets, not confirmed vulnerable deployments or valid keys.
Compare the result with cloud and DNS inventory. If an unmanaged Dify deployment belongs to the organization, review its workspace members, application keys, dataset keys, model providers, and public app settings before using it for production data.
Incident response for a leaked key
Revoke the key type that was exposed. If an application key is involved, review the application's logs and provider usage. If a dataset key is involved, review dataset access and exports. If a provider key is involved, rotate it at the provider and inspect billing and request history.
Preserve the key identifier, application or dataset ID, workspace role, and relevant logs before deleting the credential. Check whether the same secret was stored in other applications or example files.
After containment, reduce key scope, separate production and development resources, and remove standing workspace roles that are no longer needed. Dify's API is designed around resources. Security improves when the credential inventory reflects those same resource boundaries.
Top comments (0)