Does Algolia enable referer restrictions by default on search-only API keys?

Question

Algolia search-only API keys are created without HTTP referer restrictions unless explicitly configured. This opt-in model places the burden on developers to remember adding referer limits in the dashboard or via the Admin API. When omitted, the key can be used from any origin, potentially exposing index data or consuming quota if the key is extracted from client-side code. Secured API keys offer a server-side derivation path with embedded referer constraints, but they require additional implementation effort. The platform currently leaves referer restrictions disabled by default for new search-only keys, which differs from some other search platforms that enforce origin locking out of the box.

Does Algolia plan to change the default to enable referer restrictions on newly created search-only keys? What migration path would exist for existing keys if the default behavior changes? Which configuration approach—dashboard default, API parameter, or secured key derivation—best balances security and developer experience?

Tasadduq Burney · Answer

Direct AnswerNo, Algolia does not enable HTTP referer restrictions by default on newly created search-only API keys. Referer restrictions are entirely opt-in: a key is created with an empty or absent referers field unless you explicitly add one via the dashboard or the Admin API.Confirmed BehaviorCreation: Using POST /1/keys with "acl":["search"] returns a key object that has no referers array.Enforcement: The Algolia engine only checks the Referer header when the key object contains a non-empty referers list.Modification: Restrictions can be added later with PUT /1/keys/<key> and a payload such as {"referers":["https://example.com/*"]}.No Announced Default ChangeAlgolia's public documentation and recent releases (as of 2024-2025) do not indicate any plan to flip the default to "referer restrictions enabled". If such a change were introduced, the platform's standard practice would be: existing keys retain their current settings with no automatic migration; developers would be notified and could bulk-update keys via the Admin API (GET /1/keys → filter → PUT each); new keys created after the change would receive the new default.Configuration Approaches ComparedApproachSecurityDeveloper ExperienceBest ForKey-level referers (dashboard/ Admin API)Defense-in-depth; can be spoofedSimple UI or one API call per keyBrowser-based apps with a known origin listSecured API keys (server-derived)Stronger&8212;referer baked into signed token, cannot be stripped client-sideRequires backend endpoint to generate short-lived tokensSPAs, mobile apps, SSR, any scenario where the raw key should not appear in the browserNo referer restriction (current default)Relies solely on key secrecy and rate limitsZero configInternal tools, server-to-server, or when origin list is dynamic/unknownPractical Verification (Run Once)# 1. Create a search-only key
curl -X POST "https://.algolia.net/1/keys" \
  -H "X-Algolia-API-Key: " \
  -H "X-Algolia-Application-Id: " \
  -d '{"acl":["search"]}'

# 2. Inspect the response – "referers" will be absent or []

# 3. Add a restriction
curl -X PUT "https://.algolia.net/1/keys/" \
  -H "X-Algolia-API-Key: " \
  -H "X-Algolia-Application-Id: " \
  -d '{"referers":["https://myapp.example.com/*"]}'One Diagnostic Detail That Changes the RecommendationIf your frontend is a server-rendered app or mobile client that sometimes sends no Referer header, key-level referer restrictions will block legitimate traffic. In that case, prefer secured API keys with a short TTL and embed the referer (or omit it) inside the signed token instead of relying on the key-level setting.

Does Algolia enable referer restrictions by default on search-only API keys?

1 answer

Direct Answer

Confirmed Behavior

No Announced Default Change

Configuration Approaches Compared

Practical Verification (Run Once)

One Diagnostic Detail That Changes the Recommendation

Your perspective belongs here.

0 question comments

Approach	Security	Developer Experience	Best For
Key-level referers (dashboard/ Admin API)	Defense-in-depth; can be spoofed	Simple UI or one API call per key	Browser-based apps with a known origin list
Secured API keys (server-derived)	Stronger&8212;referer baked into signed token, cannot be stripped client-side	Requires backend endpoint to generate short-lived tokens	SPAs, mobile apps, SSR, any scenario where the raw key should not appear in the browser
No referer restriction (current default)	Relies solely on key secrecy and rate limits	Zero config	Internal tools, server-to-server, or when origin list is dynamic/unknown