Weaviate Security Review

Weaviate’s own default Docker command sets AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED to true, and its documentation calls anonymous access strongly discouraged outside development or evaluation. We test whether it is still switched on, and what role a request without any credentials can reach.

Why Weaviate security comes down to what RBAC and multi-tenancy actually enforce

Weaviate’s own Docker Compose guide confirms that its documented default command sets AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED to true, and its authentication documentation calls anonymous access strongly discouraged outside development or evaluation. Role-based access control is a separate switch again: Weaviate’s RBAC configuration guide turns it on through its own environment variable, and Weaviate ships with exactly two predefined roles, root with full access to every resource and viewer with read-only access to every resource; any authenticated user assigned neither has no permissions at all. Weaviate’s own RBAC overview warns that permissions to manage roles can be used to escalate privileges by assigning further roles to a user, and says they should only ever go to trusted accounts, so we test who holds that permission against who genuinely administers the deployment.

That same model scopes down to individual tenants: Weaviate’s documentation on managing roles lists a Data Objects permission that can be filtered by both collection name and tenant name, so a role can be scoped to a single tenant of a single collection rather than the whole deployment. Multi-tenancy is documented as isolation by shard, with Weaviate’s multi-tenancy guide stating plainly that data stored in one tenant is not visible to another, but which tenant a request actually reaches is chosen by a tenant identifier the calling application passes on every query, and the same guide warns that near-identical names such as TenantOne, tenantOne and TenntOne become three separate tenants once automatic tenant creation is switched on. We test whether that identifier is checked against the caller’s own account before a query runs. For the wider family of technologies this scope splits from, see our NoSQL, cache and streaming security review.

Authentication goes deeper than the three top-level methods suggest. Weaviate’s OIDC configuration reference notes that skipping the client ID audience check is not recommended because it reduces security, and its group role mapping guide is explicit that Weaviate has no API to create a group and only becomes aware of one the first time a role is assigned to it, with no automatic re-sync against your identity provider afterwards. Weaviate Cloud moves the same questions into a console: a new cluster ships with no API keys, each key is bound to a role and shown in full only once, and Weaviate’s Weaviate Cloud authorization guide confirms role changes take effect immediately for every key assigned to that role. Weaviate also runs a public disclosure programme scoped to Weaviate Cloud sandbox accounts, the console service and its open-source repository, and we confirm your own cluster’s testing terms against that scope during scoping. For how the same tool-permission and retrieval questions play out in a RAG application built on top of it, see our AI penetration testing.