Weaviate Docker deployments ship with anonymous access enabled by default

Anonymous access on by default

Weaviate, a vector database that exposes REST and GraphQL interfaces, documents that its Docker installation turns on anonymous access unless an operator explicitly disables it. According to a dev.to write-up, requests that arrive with no credentials are treated as a user named "anonymous," and the setting exists so newcomers can evaluate the database quickly. Nothing in the deployment path forces a change once the cluster starts holding real data, so a development-era configuration can quietly become a production one.

What the scan actually measured

On October 29, 2026, the author of the dev.to post ran queries on ZoomEye, a search engine that indexes internet-facing systems, asking only for match counts. A search for pages whose title contains "Weaviate" returned 59 matches, while a query built on ZoomEye's application fingerprint for Weaviate returned zero. The post is deliberately cautious about interpreting these numbers: the 59 results are candidates — a service, a documentation page, a login screen — rather than confirmed open databases, and the zero from the fingerprint query is not evidence that no Weaviate instance is reachable. A reverse proxy can strip a backend product's fingerprint while still forwarding its API traffic, which is one reason a zero result cannot function as a negative inventory check. The post recommends validating any title-only candidate against an owned hostname, a product route, or a cloud asset record before treating it as a live Weaviate endpoint.

Authentication and authorization are separate questions

Weaviate supports three authentication modes: API keys, OpenID Connect, and anonymous access. The dev.to post draws a distinction that applies well beyond this database: authentication decides who the caller is, while authorization decides what that identity may touch. Turning on API keys does not by itself tighten a deployment if every key carries root-level permissions. Weaviate's recommended production model is role-based access control, where roles constrain a principal at the level of collections, tenants, and operations. The documentation's authorization guide, cited in the post, warns that undifferentiated access suits only development or a single trusted user, and the post advises testing whether a user with access to one collection can even detect the existence of another — tenant isolation should not be inferred from collection naming.

A checklist for operators

The post closes with concrete review steps for anyone running Weaviate:

• Set AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED to false in production unless there is a deliberate public-read use case.
• Enable API key or OIDC authentication, then configure RBAC so each client service holds a role scoped to its own collections and tenants instead of reusing a root key.
• Exercise anonymous and low-privilege requests against read, write, delete, backup, and schema operations to confirm the boundaries hold in practice.
• Keep health and metrics endpoints off the public listener if they are meant to be internal.
• Monitor anonymous request volume, authentication failures, schema changes, and bulk reads. A request count is not proof of misuse, but a sudden rise in anonymous activity is a reason to inspect the deployment.
• If anonymous access was left enabled by accident, disable it and rotate any credentials reachable from the same network.

The post also suggests recording scan queries as dated measurements — exact query, result, unit, and scope — linked to the system owner, rather than as statements about who is affected.

Why it matters

Vector databases increasingly hold embeddings derived from private documents, which makes their contents leak-sensitive even when raw text is not stored directly. Weaviate's default is convenient for a first demo and becomes a liability only when it survives the move to production — a pattern common across self-hosted infrastructure images. The story is also a small lesson in reading scan data responsibly: 59 title matches is a prompt to audit your own clusters, not a vulnerability count for the ecosystem, and a zero on a fingerprint query proves nothing either way. The decisive evidence is always the live authentication and authorization configuration, not what a search engine observed on a given day.