Does a Search-Only API key prevent enumeration of an entire Algolia index from the browser?

Question

Preventing accidental public access to Algolia data requires choosing the correct API key type for client-side use. Algolia provides a tiered API key system with an Admin API Key for full read/write access, a Search-Only API Key for read-only queries, and Secured API Keys that can be signed with user-specific restrictions.

The design goal is to allow search from the browser without exposing write capabilities or data that should remain private to a tenant. The constraint is that a Search-Only key is still a read key for the entire index it is authorized against, and Secured API Keys are used to add filters and other restrictions per user.

There is uncertainty about the boundary between read-only safety and data visibility when only a Search-Only key is used.

Does a Search-Only API key allow a client to retrieve all records in an index by issuing broad queries with no filters? Which additional restrictions are required to prevent a user from accessing records outside their authorized scope when the index is shared? When is a Secured API Key with filters necessary instead of a plain Search-Only key?

Tasadduq Burney · Answer

Short answerNo. A Search-Only API key grants read/search access to the authorized index, but it does not prevent a browser client from issuing broad or empty queries and paging through results. Rate limiting and hits-per-page caps may slow enumeration, but they are not access control.Confirmed behaviorA plain Search-Only key restricts index-level access and write operations; it does not enforce record-level visibility inside a shared index.Any holder of the key can run empty queries, paginate, and potentially retrieve many or all records in that index.A Secured API Key is generated server-side from the Search-Only key and can attach per-user filters such as user_id or tenant_id, plus optional validUntil and rate limits.The signing key must never be exposed in browser code.Steps for this caseDetermine whether the index holds only public data or records belonging to multiple users or tenants.If all data is public, a plain Search-Only key in frontend code is acceptable, with Algolia rate limits enabled.If the index is shared, generate a Secured API Key on the server for each user or session, attach a filter that limits results to that user's records, and give the browser only the secured key.Verify in browser DevTools that frontend requests use the intended key and that records outside the user's filter do not appear.Assumptions and uncertaintyThis answer assumes the standard Algolia API key model: Admin, Search-Only, and Secured keys. Specific limits such as maximum hitsPerPage and secured-key options can change; verify against current Algolia documentation before production use. The research flagged this topic as requiring current verification, so treat exact limits as unconfirmed until checked.Missing diagnostic detailIs the index shared across multiple users or tenants, or does it contain only data that every browser user is allowed to see? This determines whether a plain Search-Only key is sufficient or a per-user Secured API Key is required.

Does a Search-Only API key prevent enumeration of an entire Algolia index from the browser?

1 answer

Short answer

Confirmed behavior

Steps for this case

Assumptions and uncertainty

Missing diagnostic detail

Your perspective belongs here.

0 question comments