Dify deployments need a boundary between app keys and console authority

#zoomeye #dify #ai

Dify deployments need a boundary between app keys and console authority

Self-hosted Dify installations combine an application-building console, runtime APIs, worker services, and a sandbox used by workflow code. They can be valuable to an organization and easy to place on the internet without a clear ownership record. For a Dify deployment, the useful inventory starts with which parts are reachable, which credential controls each part, and whether an application key has been mistaken for console authority.

At about 23:48 UTC on 29 October 2026, count-only ZoomEye SDK queries with sub_type=all and page size 1 returned 12,952 matches for app="Dify" and 11,189 for title="Dify". These are asset observations, not confirmed vulnerable installations. The difference between the fingerprints also means the two numbers should not be merged into one population. The app query is the primary observation for this article, but it does not prove authentication state or version.

Separate the planes

The console is used to create and administer applications, datasets, and workspace settings. An application API key is intended for calls to a published app and is scoped to that app. The two should not share a browser session, reverse-proxy rule, or credential distribution path. An internet-facing console needs strong administrator authentication and network policy; an application API may need a different route, rate limit, and key rotation process.

Review every reachable hostname and path, including the API, console, web front end, worker health endpoint, and sandbox service. A public web UI does not mean the internal services must be public. Put the management plane behind an identity-aware proxy or private network and require a separate approval for changes to workspace-wide configuration.

Inventory application keys as identities

Each application key should have an owner, environment, upstream app, permitted data sources, issue date, and replacement plan. Store the secret in a secrets manager, not in a repository or a static front-end bundle. Confirm the key cannot be used against a different application or the console. Test the negative case: use a valid key with the wrong app identifier and verify the service rejects the request.

Look at the data path after authentication. A workflow can call external tools, read datasets, execute code in a sandbox, or invoke a model provider with a separate credential. The application key's scope is only one part of that chain. An unprivileged caller should not be able to choose arbitrary sandbox code, call an internal metadata service, or reach a credential that belongs to a different workflow.

Inspect the deployment evidence

Use ZoomEye and internal asset data to find Dify fingerprints, then verify ownership through DNS, cloud inventory, and an authenticated owner. Record the public endpoint, response headers, TLS certificate, and authentication challenge. Do not attempt to bypass a login or test credentials you do not own. For an authorized assessment, confirm whether the console has MFA, whether default accounts remain, whether SSO is enforced, and whether administrative changes are logged.

The public count is useful for prioritization. It tells a security team that Dify is a recognizable part of the internet's application layer and that the organization should be able to find its own deployments. It does not tell them that every matching asset is exploitable or that a self-hosted instance has the same configuration as the next one.

Make the boundary observable

Alert on new internet-facing console hostnames, changes to the public API allow list, and application keys that are used from a new network or with a sudden increase in volume. Keep an audit trail of app creation, key replacement, member invitations, and dataset connections. A console login and an application API call should produce distinguishable events.

The practical test is to ask who owns the console, which applications are published, which keys are active, and which sandbox or tool credentials each workflow can reach. If those answers live in different teams with no shared inventory, a public Dify page is a symptom of missing governance as much as a possible configuration issue.