Algolia Integration Security Review

An Algolia API key can combine any of 13 access control list permissions in one string, from search and browse through to deleteIndex and editSettings, with nothing in the key itself to separate one that can query an index from one that can rewrite it.

Why an Algolia integration’s security is decided by which key reaches the browser

Algolia’s own documentation on API keys names two predefined keys: a Search-only API key it calls safe to use in your production frontend code, and an Admin API key that gives access to everything in the account, including every index, and should remain confidential. Custom keys sit between the two, each built from any combination of 13 access control list permissions, from search and browse through to deleteIndex, editSettings and seeUnretrievableAttributes, plus a separate set of optional restrictions covering which indices a key reaches, a per-hour rate limit, a cap on records retrieved, an expiry, allowed HTTP referrers and enforced query parameters. None of that scope is visible from the key’s name or the variable it is stored in; a string called SEARCH_KEY is only a search-only key if its ACL was actually built that way.

For scoping search to a single tenant or user, Algolia’s generateSecuredApiKey method builds a virtual key from a parent key plus a set of restrictions, computing a SHA-256 HMAC with the parent key as the secret and the restrictions as the message; Algolia’s reference is explicit that at least one restriction is required, that a secured key built with the same restrictions as its parent is rejected with a 403, and that an Admin API key can never be used as the parent. Because the parent key is the secret in that calculation, the method only works safely on a server that already holds it: generating a secured key in the browser means shipping the parent key there to compute it, which removes the restriction it was meant to add. Deleting the parent key deletes every secured key derived from it in one action, and Algolia’s documentation confirms a deleted secured key cannot be individually restored even if the parent is. A userToken parameter exists so that many users sharing one IP address are not rate-limited as if they were one user; it does not enforce a tenant or user boundary on its own, which is set entirely by the filters and restrictIndices values baked into the key.

Two index settings decide what a search response can actually expose. unretrievableAttributes excludes named, case-sensitive fields from every response unless the request authenticates with the Admin API key, which makes it the setting for a field used to rank, filter or restrict results that end users should never see directly. attributesToRetrieve works the other way round: objectID is always returned regardless of the setting, a bare wildcard returns every attribute, and Algolia’s own documentation gives a hyphen-prefixed exclusion combined with that wildcard as the way to hide a value such as a custom ranking attribute without removing it from the index. Algolia’s shared responsibility documentation is explicit that Algolia secures the infrastructure and the API key and ACL mechanism itself, while which indices exist, what a key’s restrictions actually enforce and what unretrievableAttributes hides is the customer’s configuration to get right. We test that configuration, not Algolia’s platform. For the wider family of search, cache and streaming systems this scope splits from, see our NoSQL, cache and streaming security review.