Security Best Practices

Security is key to Algolia. Algolia follows the work of the security research community to keep improving the security of your Algolia data and applications. As much as we strive to keep your data secure, security is a shared responsibility between Algolia and its users. You need to apply all security best 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 best practices and in-depth security guides to get a good grasp of what falls under your responsibility.

Two-factor authentication

First, you need to 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 who have 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.

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.

Securing your API keys

Algolia provides predefined API keys and lets you create new ones with fine-grained access control lists (ACL). 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. 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 front-end code, or in a mobile application, because this source code runs on the end user’s device. You should also be careful when using such keys in your back-end code, and use environment variables to inject your keys rather than hard-coding 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 it’s best to inject your API keys with environment variables, Algolia isn’t responsible if your CI/CD service experiences a security incident and leaks your keys. Additionally, you’re responsible for ensuring that the services you use are safe, and for properly using the features they offer.

Securing 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 the Algolia support team.

You must 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.

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 applications, you should 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.

You shouldn’t hard-code API keys in mobile applications. Instead, fetch 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 hard-coded 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.

Separating your environments

To avoid mistakes, you should 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 application, you can select the parts of the application 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.

Additionally, you need to 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. Also, make sure to use a company email address for the account owner instead of an individual one, so you don’t lose access to Algolia when this person leaves or is unavailable.

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 Algolia support if you need to.

Sensitive information

Algolia implements state-of-the-art practices when it comes to ensuring that your data is safe and isolated from other Algolia users. There are many ways for you to prevent access from unauthorized users, such as Secured API keys or unretrievableAttributes and with Algolia Vault. When dealing with sensitive information, you should use these features.

When it comes to sensitive data, you need to make sure to never use it within metadata, which could, for example, appear in logs. For example, you must never use sensitive information in an index name. Index names appear in network requests, so you should consider them publicly available. For example, in the context of a medical application where you would have one index per user and per medical condition, never use the user or patient name and the name of the medical condition as the index name.

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 other restrictions.

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

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

When implementing Click and Conversion Analytics, 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 both HTTP and HTTPS for search operations.

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

HTTP referrers restrictions

Browsers send referrer source URLs, 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 (for example, cURL). To prevent unauthorized access to your data, such as ensuring that each user only sees their own data, you can use Secured API keys.

There’s still a valid use case for the Referer header. Since most 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 before, 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:

• 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 for the full algolia.com domain, you can use *algolia.com/*.

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.