Chroma is a vector database used for retrieval over embeddings, documents, and metadata. A self-hosted Chroma server can contain internal documents, customer records, model outputs, and security-sensitive context. Exposing the server or its API is therefore a data-boundary issue, even when no vulnerability is known.
A ZoomEye count-only measurement on October 31, 2026 at 06:44 Beijing time used page 1, page size 1, and sub_type=all. app="Chroma" returned 0 matches and title="Chroma" returned 1,215. The title count can include documentation and unrelated web pages. It does not show that 1,215 vector databases are reachable or that their collections are readable.
Use the counts with the right question
The app query is a narrow product-fingerprint question. A zero result means that the exact signature did not appear in the selected scope, not that no Chroma deployment exists. A reverse proxy, custom health response, or nonstandard deployment can change discovery evidence.
The title query is a broader discovery signal. A site may present a customized interface while the title still names the product. Alternatively, the title may belong to a project page, a tutorial, or an unrelated product name. Resolve the candidate through an owned asset record and a safe public response check. Do not query an unowned collection or attempt to enumerate embeddings.
Review server authentication
Chroma documentation describes authentication for server and client mode. The supported methods include basic authentication and a static API token, with the documentation marking these mechanisms as alpha. The exact server version and deployment configuration determine which method is available and how it is enabled.
For an owned deployment, record whether authentication is enabled, where the credential is stored, how it is rotated, and which clients use it. Put the server behind TLS and a network policy that limits access to the applications that need it. Do not expose the server directly to the internet when a controlled gateway can provide authentication, logging, and source restrictions.
A static token can become a shared master credential. Separate development and production tokens where the deployment permits it, and remove tokens for retired jobs. Test a request without credentials, a request with a revoked token, and a request from an unapproved source. Confirm that the gateway and the Chroma server agree on the expected authentication path.
Protect collection data and metadata
A collection can reveal more than the embeddings. Documents, metadata filters, collection names, and query results may expose business information or personal data. Review who can list databases and collections, add or delete records, and query across them. If the application supplies tenant identifiers, verify that every query is scoped server-side and cannot be changed by a client parameter.
Back up the Chroma data and the configuration that identifies its storage. Protect backups as sensitive data, not as opaque model artifacts. Test a restore with an isolated client and verify collection counts, query behavior, and authentication. Rotate credentials after a restore from an untrusted copy.
Check the embedding source. A document may contain secrets or personal data that the original application would not expose through its normal interface. Data retention and deletion policies should cover the vector store as well as the source content.
Turn discovery into evidence
A practical inventory records the hostname, owner, environment, Chroma version, authentication method, network path, exposed collections, client applications, backup owner, and last restore test. Add the exact ZoomEye query, count, time, and scope that led to the review.
Use the count to find candidates. Use the owned configuration and a controlled query to determine what data is reachable. A public page that mentions Chroma is not enough to claim that an API or collection is exposed.
Conclusion
Chroma's 0 app and 1,215 title matches describe discovery evidence, not confirmed data exposure. The useful review connects server authentication, network restrictions, collection authorization, backups, deletion, and query logging. Those controls determine whether a vector database is a controlled internal service or an unowned copy of sensitive business data.