Question
Unauthenticated search key exposes all indexed records: Algolia default access control
Sky Indigo
0 reputation · 29 May 2020, 16:37 UTC
32.3K views1
Loading…
0 reputation · 29 May 2020, 16:37 UTC
When embedding Algolia search in a public frontend, the search-only API key is visible to every client, so its default access scope determines whether indexed data remains private. Algolia's documented security model indicates that unauthenticated search keys may have read-only access to all searchable attributes and records unless index-level restrictions are explicitly configured. The uncertainty is whether current defaults automatically limit exposure or whether every index requires manual restriction through settings such as restrictToPattern and attributesToRetrieve.
Differences across Algolia dashboard versions may affect how these restrictions are applied, making it unclear whether a key configured in one release behaves identically in another. Without a dependable verification method, teams cannot easily confirm that a frontend search key is not exposing unintended attributes to unauthenticated users.
Does the default Algolia search-only API key restrict access to specific indices and attributes, or does it expose all searchable records unless manually constrained? How do dashboard version differences affect the enforcement of index-level restrictions on search keys? What verification approach reliably confirms that an unauthenticated search key is not exposing unintended attributes?
35275 reputation · 30 May 2020, 02:36 UTC
No. A default Algolia search-only API key does not automatically restrict itself to specific indices or attributes. Unless the key is explicitly constrained, an unauthenticated frontend client can generally search every index in the application and receive all searchable attributes for matching records. The key being visible in browser source is expected by design; the actual exposure risk is an over-broad scope, not the visibility itself.
Confirmed: Algolia enforces API key access control at the service layer using the key's stored ACL, permitted indices, and queryParameters. attributesToRetrieve controls which fields are returned, while indices controls which indexes the key may target. Dashboard version differences mainly change the configuration UI; enforcement depends on the stored key definition, not the dashboard release used to create it.
Uncertain: default behavior can vary by account creation flow and Algolia plan, so there is no universal default you can safely assume without inspecting the specific key. Current verification is required before treating any key as restricted.
algoliacurl "https://${ALGOLIA_APP_ID}-dsn.algolia.net/1/keys/${SEARCH_KEY_ID}" -H "X-Algolia-Application-Id: ${ALGOLIA_APP_ID}" -H "X-Algolia-API-Key: ${ALGOLIA_ADMIN_API_KEY}"Check acl for search permission, indices for the allowed indexes, and queryParameters.attributesToRetrieve for field limits.
Do you have an Admin API key for this application so you can inspect the live search-only key's stored ACL and index list? Without admin access, verification cannot proceed, and the safest interim assumption is that the key is unrestricted.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.