Typesense Security Review

Typesense’s own quickstart and Docker examples start a cluster with exactly one bootstrap API key, created with actions set to * and collections set to *, valid for every action on every collection until a narrower key replaces it.

Why Typesense security comes down to which key reaches your application

Typesense’s own API keys documentation shows the bootstrap key, the one generated from the –api-key value a cluster is started with, as a record with actions set to [“*”] and collections set to [“*”]: full access to every action on every collection. The same page states it is strongly recommended not to use that bootstrap key directly in production applications, generating an appropriately scoped key for the application at hand instead. Keys created afterwards carry their own actions list, from documents:search through to documents:create, documents:delete or documents:*, and their own collections list, and the API only ever returns a key’s full value once, at creation; retrieving it later returns just a short value_prefix. We map every bootstrap and scoped key your application actually uses against what each one’s real actions and collections allow.

For multi-tenant data, Typesense documents generating a scoped search key with generate_scoped_search_key, which takes a parent key that already carries a search-only scope and computes an HMAC digest of the embedded parameters with it, the same class of mechanism Algolia’s secured keys use to derive a restricted key without a server round trip, as covered on our Algolia integration security review. Typesense’s own documentation names indexing several customers’ data in one collection and issuing each tenant a scoped key with an embedded filter_by value as a named use case, and confirms any other search parameter, such as exclude_fields or limit_hits, can be embedded the same way specifically to stop a client changing it. We test whether every tenant-facing key actually carries its own filter_by, and whether the parent key used to sign it holds anything wider than search.

Typesense Cloud adds a layer on top of that same key-based API: a cluster’s cors-domains configuration parameter accepts only a comma-separated list of HTTPS URLs with no wildcard support, its dashboard splits access into five named roles from Administrator down to Billing Manager, and a team can turn on SAML single sign-on so that adding a new user only means granting them access to the SSO app in the identity provider. We review whichever of these layers apply to your deployment, self-hosted or Cloud, against the same standard: does the key or role in front of a person or integration actually match what they need.