Meilisearch Security Review

Meilisearch’s own API reference documents a bare * in a key’s actions array as the way to grant every permission it supports, from search through to keys.delete and network.update, in one string with nothing in the key format itself marking it as unrestricted.

Why a Meilisearch API key’s reach is decided by its actions and indexes arrays

Meilisearch’s own authorisation reference says providing a master key at launch is what protects a self-hosted instance from unauthorised requests, that the key must be at least 16 bytes, and that from then on every route except /health needs a valid API key in the Authorization header, with the /keys route reachable only by the master key itself. Meilisearch Cloud removes the setup step rather than the risk: its security guide confirms a master key is generated automatically for every project, which is then used to create four default keys: a Default Search API Key, a Default Admin API Key documented as granting full access to all operations except managing other keys, a Default Read-Only Admin API Key with read-only access to the whole database, and a Default Chat API Key scoped to search and chatCompletions.

Beyond the four defaults, Meilisearch’s key reference documents a custom key’s actions as a list of granular permissions, including documents.add, indexes.create, settings.update, network.update and keys.delete, and states plainly that a bare * grants every one of them in a single string; the indexes field works the same way, accepting * for every index including ones created later, or a prefix pattern such as movies_* that the documentation gives as a working example. Once a key exists, Meilisearch’s key-management guide says its actions, indexes and expiresAt fields cannot be changed, a key created without an expiry can never have one added later, and an expired key’s requests return a 403, which is why what a key was actually built to do at creation matters more than what it is called.

Multi-tenant search moves the same question into tenant tokens rather than the parent key itself. Meilisearch’s tenant token payload reference documents them as JSON web tokens carrying searchRules, an API key UID and an optional expiry, built with a header specifying HS256, HS384 or HS512 and then signed with an API key, and its own security guide is explicit that a tenant token restricts only the search endpoint, never indexing, settings updates or API key management, and likens the whole mechanism to Algolia’s secured API keys. We test that filter, that signing key and the plain API keys behind them, not Meilisearch’s own hosting. For the wider family of search, cache and streaming systems this scope splits from, see our NoSQL, cache and streaming security review.