Guides / Security

Security Best Practices

Security is key to us. We closely follow the works of the security research community and implement every best practice that can improve the overall security of our applications. We actively work on preventing the crawling of your data, hacking of your account, human mistakes, access to your confidential information; anything undesirable that could happen.

While much of the security work happens on our side, there are best practices you should follow when using Algolia, to ensure that your account and data are completely secure.

Shared responsibility

As much as we strive to keep your data secure, some things remain out of our control. Security is a shared responsibility between Algolia and its customers, and you need to apply all our recommended practices to avoid exposing your data and account.

These practices range from how you manipulate sensitive information to whom you give access to your Algolia account and how. Make sure you go through all our best practices and in-depth security guides to get a good grasp of what falls under your responsibility.

General best practices

Two-factor authentication (2FA)

First, you need to secure access to your dashboard, as it contains access to all your API keys and data. We strongly recommend enabling two-factor authentication (2FA) for all users who have access to your dashboard.

Go to My account on your Algolia dashboard, enable Two-factor authentication, and save. You can use the Google Authenticator mobile app (available on iOS and Android) to scan the generated QR code and confirm your 2FA access.

Every member of your team needs to activate 2FA on their account to secure your application.

If you lose access, you need to reset two-factor authentication on your account.

Secure your Admin API key

The Admin API key of your account provides full control over your account and all your indices. For that reason, it must remain confidential. You should never share it with anyone, including our support team.

You should never use your Admin API key in any application. Its role is to generate other, more limited keys to use for searching and performing indexing operations.

If you believe your Admin API key has been compromised, you can renew it in the API Keys section of the dashboard. This immediately revokes the old key.

ACL for your members

When you invite a member of your team to an Algolia application, you can select the parts of the application they have access to with an access control list (ACL). Make sure that each member only has access to the right set of features. You can also limit the set of indices that someone has access to.

For now, only the account owner can add or remove users from the team. You can’t change the account owner on your side, but you can contact us if you need to.


Our API requires HTTPS for indexing operations and authorizes both HTTP and HTTPS for search operations.

However, we recommend using HTTPS for search operations as well. This is automatic if your web or mobile application uses HTTPS already, and you’re using one of our API clients or InsantSearch UI libraries.

Separating your environments

To avoid mistakes, we recommend separating your development environments and using a different API key for each.

Unretrievable attributes

You may want to index some information on Algolia that you don’t want users to access. For example, you may want to index a sensitive business metric such as number of sales so you can use it as part of your custom ranking, but you don’t want the raw data to be available to the outside world.

To prevent this, you can set a list of unretrievableAttributes to exclude them from the search response.

You can still retrieve unretrievableAttributes by using the Admin API Key. This should only happen in debugging situations.

API key security

In addition to the general best practices, you need to secure your API keys. There are many limitations you can set on your API keys to ensure that users can only access what they’re supposed to and prevent the crawling of your data.

Guides API Keys

API keys rotation

We recommend regenerating all your API keys at least once a year. It gives you an additional level of security in case one of your API keys leaks, is used in projects that don’t belong to you, or if you need to for compliance reasons.

For highly sensitive applications, we recommend rotating the keys more often, but one year should be the maximum lifetime of an API key.

API keys in mobile applications

Mobile applications represent significant security risks for your API keys and make security operations more difficult.

You shouldn’t hardcode API keys in mobile applications. Instead, we recommend fetching them dynamically from your application’s back end. The reason is that users might not update your application as often as you’d want. If you need to rotate an API key that was hardcoded in your mobile application, the application stops working.

Please note that there are tools to extract information from mobile applications. Make sure never to give your mobile application API keys more privileges than necessary, and use Secured API keys with expiration times.

Content Security Policy

Content Security Policy (CSP) is a recent addition to the browser security stack. It lets you define authorized resources, domains to perform XHR requests to, allow HTTP or not, and many more.

When you’re implementing CSP, use the following policy for the Javascript API client to work properly:

connect-src https://* https://*;

When implementing our Click Analytics API, consider the following policy:

connect-src https://* https://* https://*;

HTTP referrers restrictions

The referrer source URL is sent by browsers, either through the Referer or the Origin HTTP header. Like all HTTP headers, it can be spoofed, so you shouldn’t rely on it to secure your data. For example, while Referer should always be valid when requesting from a browser, it can be overridden when using other tools (e.g., cURL). To prevent unauthorized access to your data, such as ensuring that each user only sees their own data, we recommend using secured API keys.

There’s still a valid use case for the Referer header. Since browsers send it with every request, you can use it to restrict the usage of your API key to your own website. This prevents another website from “stealing” your key, for example, to harvest ad clicks with your data. As stated above, this doesn’t prevent them from scraping the data with other tools. To mitigate that risk, you can restrict which HTTP referrers you accept and you can rate limit API keys.

Some browsers intentionally remove the Referer and Origin headers from third-party requests. If you’re using a search API key with restrictions on the referrer, this will prevent users from searching on these browsers.

Authorized HTTP referrers

You can define a list of referrers authorized to query the API with a given key. If unspecified or empty, it defaults to any referrer.

You can target referrers by matching a prefix or a suffix using the * wildcard:

  •* restricts access to all referrers starting with
  • * restricts access to all referrers ending with
  • To allow access for the full domain, you can use **.

Blocking IPs

If you experience a sudden and unusual increase in query operations, then there might be something wrong with your implementation. That could also be due to users or bots sending an abnormal amount of requests to your site.

When this happens, you may want to block IP addresses that are excessively triggering operations. Note that you need to implement this on your end, this isn’t an Algolia feature.

Did you find this page helpful?