Search‑Only Key vs. Server‑Side Proxy: Which Limits Public Exposure Better?

Direct Answer

A server-side proxy limits public exposure better than relying on a search-only key alone. The proxy keeps the private signing or admin key off the client, can redact fields before they reach the browser, enforce per-user filters, and log queries. A search-only key should be treated as already public because it can be extracted from browser code, and referrer restrictions are easily bypassed.

Confirmed Facts vs. Likely Explanation

Confirmed behavior

• Algolia search-only keys can be embedded in client code, but anyone with access to the page can extract and reuse them.
• Index-level unretrievable attributes prevent a field from being returned unless seeUnretrievableAttributes is granted; they do not hide the fact that a record matches a query.
• Key revocation is not instantaneous across all clients; cached or embedded keys may continue working until propagation, cache expiry, or app rotation.
• A proxy introduces one extra network hop and requires availability, authentication, logging, and key rotation maintenance.

Likely explanation for the trade-off

If no indexed attribute is sensitive, a search-only key with unretrievable attributes may be sufficient. If any attribute must be hidden from some users, or if you need audit logging and per-user filtering, the proxy’s latency and maintenance cost are usually justified.

Steps for This Case

1. Mark sensitive attributes as unretrievable at the index level.
2. Create a search-only key that does not include seeUnretrievableAttributes.
3. Verify that requesting the sensitive attribute in attributesToRetrieve returns it as null or omits it while other attributes still return.
4. If the attribute must be hidden conditionally per user, add a server-side proxy that signs secured keys with filters and validUntil, then forwards only allowed parameters to Algolia.
5. Never embed the private admin key or the secured-key signing secret in browser code.

Missing Diagnostic Detail

Do any indexed attributes contain data that must be hidden from specific users, or is the entire index equally searchable by everyone? This determines whether a search-only key suffices or a proxy is required.

Assumptions and Uncertainty

• This assumes Algolia cloud search with standard ACLs; exact key names and propagation delays vary by SDK and plan.
• Revocation delay is expected to be brief but not zero; treat it as a risk window, not a guarantee.
• Proxy latency is measurable but workload-dependent; no universal threshold makes it mandatory or unnecessary.

Verification

1. In a sample index, mark one attribute unretrievable, create a search-only key without seeUnretrievableAttributes, request the attribute, and confirm it is omitted.
2. Compare direct browser-to-Algolia latency with browser-to-proxy-to-Algolia under load.
3. Confirm current ACL and unretrievable-attribute behavior for your Algolia SDK and plan before relying on field-level restrictions.