A Flowise chatflow can be protected by an API key and still execute nodes that use stored third-party credentials. The key controls who can call the flow, not what secrets the flow can reach. A review that stops at the public endpoint misses the credential store, the node permissions, and the external systems the flow can access.
Flowise documentation describes chatflow-level authorization with a generated API key and an Authorization header. It also states that an unauthenticated public chatflow API or embedded chat can be accessed by anyone. The environment documentation says Flowise encrypts third-party API keys as credentials using an encryption key, and SECRETKEY_PATH controls where the secret key is stored.
Separate three trust zones
The first zone is the person or application calling the chatflow. The second is the running flow, including tools, HTTP nodes, vector stores, and model providers. The third is the credential store and its encryption key. An API key in the first zone should not imply access to the third.
Inventory each flow's exposed endpoint, authentication setting, allowed users, and external integrations. Identify which credential IDs it references without printing the secret values. Limit the flow's ability to call arbitrary HTTP endpoints or shell tools unless that capability is reviewed.
Protect the credential encryption key
Store SECRETKEY_PATH on persistent protected storage with restricted filesystem permissions. Back it up separately from the database and test restoration. If an attacker obtains both the encrypted credential database and the encryption key, the UI length difference for a credential API key does not provide protection.
Rotate the encryption strategy through a planned migration, not by replacing the key in place without a re-encryption process. Confirm that worker and web processes use the same key and that a restart does not create a new key without the operator noticing.
Public endpoints need independent controls
An embedded chat or public API may be a legitimate front door. Add authentication at the reverse proxy or application layer when the flow can spend money, query private data, or call internal systems. Apply rate limits, request-size limits, timeout controls, and output filters. Log the flow ID and caller identity without logging complete prompts that may contain personal data.
Test whether a chatflow API key can be used against another flow. Test an unauthenticated request to each public and private path. Check CORS, cache headers, and whether the browser exposes the key in client-side code.
What the ZoomEye observation shows
The count-only measurement used sub_type=all, page 1, and page size 1. app="Flowise" returned 40,899, title="Flowise" returned 42,439, and http.body="Flowise" returned 485,939. The body count is large and can include documentation, examples, and unrelated references. A public Flowise fingerprint is a discovery lead, not proof that a credential is exposed or that a flow is exploitable.
Correlate owned instances with cloud tags, DNS, certificate names, and expected business units. If a development instance is public by mistake, disable its external access before investigating individual flows.
Review before expanding use
Create a flow inventory with owner, purpose, external credentials, data sources, and endpoint authorization. Review it when a new tool node is added, not only at deployment. The security boundary is the combination of caller identity, flow capability, and secret access.