Security best practices

Algolia strives to keep improving the security of your data and apps. But security is a shared responsibility between Algolia and you, the user.

To avoid exposing your data and account, apply all these security best practices, ranging from handling sensitive information to how and to whom you give access to your Algolia account.

Two-factor authentication

First, secure access to your dashboard, as it gives access to all your API keys and data. You should enable two-factor authentication (2FA) for all users with access to your dashboard.

Go to Account details) 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.

If you lose access, reset your account’s two-factor authentication.

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

Securing your API keys

Algolia provides predefined API keys and lets you create new ones with fine-grained access control lists (ACL). You can set many limitations on your API keys to ensure that users can only access what they’re supposed to and to prevent the crawling of your data. Algolia generates and stores these keys securely and encrypts the virtual ones. You’re responsible for how you use these keys on your end. For example, you should never have an API key with write access in frontend code or a mobile app because this source code runs on the end user’s device. Be careful when using such keys in your backend code, and use environment variables to inject your keys rather than hardcoding them. That adds an extra layer of security in case your source code leaks.

Algolia isn’t responsible for third-party services you may use. For example, while injecting your API keys with environment variables is recommended, Algolia isn’t responsible if your CI/CD service experiences a security incident and leaks your keys. You’re responsible for ensuring that your services are safe and correctly using these services’ features.

Securing your Admin API key

Your account’s Admin API key controls your account and all your indices. For that reason, it must remain confidential: never share it with anyone, including the Algolia support team.

Never use your Admin API key in any app. Use it to generate other, more limited keys for searching and performing indexing operations.

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

API key rotation

You should regenerate 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 apps, rotate your keys more often. 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. Don’t hardcode API keys in mobile applications. Instead, fetch them dynamically from your app’s backend with only the necessary authorization. The reason is that users might not update your app as often as you’d want. The app will stop working if you change a hardcoded API key in your mobile app.

Some utilities can extract information from mobile apps. Never give your mobile app’s API keys more privileges than necessary: use secured API keys with expiration times.

Separating your environments

To avoid mistakes, separate your development environments and use a different API key for each.

Team management and ACL

• When you invite a team member to an Algolia app, select the parts of the app they have access to with an access control list (ACL). You’re responsible for making sure each member only has access to what they’re supposed to, no more.
• Ensure that you remove access to members who leave your team. Algolia isn’t responsible for what team members with authorized access may do on your account and can’t help you if they perform irreversible operations. For those reasons, it’s best to invite team members with their professional email addresses rather than personal ones, so you can safely revoke access when they leave.
• Use a company email address for the account owner instead of an individual one, so you retain your Algolia access when this person leaves or is unavailable. If you want to change the account owner, contact Algolia support.

Sensitive information

How does Algolia protect your data?

Algolia implements the latest best practices to ensure that your data is safe, secure, and isolated from the data of other Algolia users. Algolia provides multiple options for you to prevent access from unauthorized users, such as secured API keys, unretrievableAttributes, and Algolia Vault. Use these features when dealing with sensitive information.

What should you do to keep your data safe?

• Never use sensitive data within metadata. For example, some types of logs could store metadata that holds this sensitive data.
• Never use sensitive information in an index name. Since index names appear in network requests, consider them as being publicly available. For example, in a medical app with one index per user and medical condition combination, don’t use the user name, patient name, or medical condition as the index name.
• Never use personally identifiable information (PII) as userToken parameter in Search or Insights API requests.

What internal logs does Algolia keep?

Algolia keeps logs for your Search API and Insights API calls. Algolia Analytics then processes these logs.

Search API logs

Algolia retains your Search API logs (for processing and auditability) for 90 days in the region you specified when choosing your plan.

Your Search API logs include:

• Algolia application ID
• Index name
• Truncated request IP address for successful calls and full request IP address for failed calls with 4xx/5xx status (for investigation and auditability)
• userToken
• Input query
• Applied filters
• Analytics tags
• HTTP headers
• Obfuscated API key
• Returned objectIDs

Insights API logs

Algolia retains your Insights API logs (for processing and auditability) for 90 days in the region you specified when choosing your plan.

Your Insight API logs include:

• Event details for successful API calls
• Algolia application ID
• Obfuscated API key
• Truncated request IP address
• User agent

Analytics

Algolia Analytics processes Search API logs and Insights API events to build aggregates.

The app log region retains your analytics data for the time specified in your Algolia plan. See Extending the retention period of the analytics data? for more details.

Content security policy

Content security policy (CSP) is an HTTP response header that lets you restrict allowed resources and domains. When you’re implementing CSP, use the following policy for Algolia:

1
connect-src https://*.algolia.net https://*.algolianet.com;

If you’re sending Insights events, consider the following policy:

1
connect-src https://*.algolia.net https://*.algolianet.com https://*.algolia.io;

HTTPS security practices

The Algolia Search API requires HTTPS for indexing operations and authorizes HTTP and HTTPS for search operations.

However, you should also use HTTPS for search operations. This is automatic if your web or mobile app already uses HTTPS and you’re using one of the officially supported API clients or InsantSearch UI libraries.

HTTP referrers restrictions

Browsers send referrer source URLs through the Referer or the Origin HTTP header. Like all HTTP headers, it can be spoofed, so don’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 (for example, curl). Use secured API keys to prevent unauthorized access to your data, such as ensuring that each user only sees their own data. To prevent unauthorized access to your data, such as ensuring that each user only sees their own data.

Since most browsers send the Referer header with every request, you can use it to restrict the usage of your API key to your website. This prevents another website from “stealing” your key, for example, to harvest ad clicks with your data. However, they can still scrap the data with other tools. To mitigate that risk, you can restrict which HTTP referrers you accept and 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.

Target referrers by matching a prefix or a suffix using the * wildcard:

• https://algolia.com/* restricts access to all referrers starting with https://algolia.com.
• *.algolia.com restricts access to all referrers ending with .algolia.com.
• To allow access to the entire algolia.com domain, use *algolia.com/*.

Blocking IP addresses

If you experience a sudden and unusual increase in query operations, there may be issues with your implementation, but it could also be due to users or bots sending an abnormal number of requests to your site.

When this happens, you may want to block IP addresses that are excessively triggering operations. You must implement this yourself: it isn’t an Algolia feature.

Further reading