Security Best Practices

Introduction

Security is key to us. We follow very closely 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 data, and anything that can potentially happen.

While a lot of the security work is done on our side on the background, there are some best practices that you should follow when using Algolia. In this guide, we want to share the features and best practices you must follow to ensure your account and data are completely secure.

General Best practices

Two-factor Authentication (2FA)

The first step is to ensure that access to your dashboard is secure as it contains access to all of your API keys and data.

We recommend enabling the two-factor authentication (2-FA) for any user that has access to your dashboard.

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

NOTE: Every member of your team needs to activate 2-FA to secure your account.

If you lose access to the 2FA on your account, you will have to reset your two-factor authentication.

Secure your Admin API Key

The ADMIN API key of your account should never be shared with anyone and must remain confidential. It provides full control over your account and all of your indices.

Should you have any reason to believe it has been compromised, you can quickly renew your ADMIN API key in the API Keys section of the dashboard. This renewal will immediately revoke the old key.

This API key should almost exclusively be used to generate other - more limited - API Keys that will be used to search and perform indexing operations.

Admin API key should never be used in any application and should only be used to generate other keys. This will allow you to rotate your new keys but the Admin API key is only one at any time.

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 (ACL). Make sure that each member only has access to the right set of features. You can also limit the set of indices someones has access to.

For now, the only person that can add/remove people from the team is the account owner. You cannot change the account owner on your side, but you can contact us if necessary.

HTTPS

Our API requires HTTPS for all index-related operations, and authorizes both HTTP and HTTPS for search operations.

We recommend using HTTPS API calls for the search operations performed on your web or mobile application (it will automatically be the case if your application is using HTTPS and you’re using one of our API clients).

Separating your multiple environments

To avoid mistakes, we recommend separating your different development environments, and using a different API key for each environment. We’ve written a guide dedicated to explaining how to setup multiple environments.

Unretrievable Attributes

You may want to index some information on Algolia that you don’t want to be accessible to your users.

That can for example be the case for the information contained in the attributes used in your customRanking.

Let’s take the example of an e-commerce site. You may want to use the number of sales of your products as a ranking strategy: customRanking=['number_of_sales']. To do that, you would need to index on Algolia the number of sales for each product of your catalogue. Someone could then use your search API Key to retrieve this confidential information.

To prevent this you can set a list of unretrievableAttributes that cannot be retrieved using your search API Key.

set_unretrievable_attributes

unretrievableAttributes can still be retrieved by using the ADMIN API Key, to help in some debugging situations.

API Key security

In addition to the general best practices, you should secure your API Keys. There are a lot of limitations you can set on your API Keys, to ensure that your users can only access what they are supposed to and prevent the crawling of your data using the API-Keys. We wrote a specific guide on API Keys and Secured API Keys.

API Keys rotation

Every API key should be regenerated at least once per year. This will give you an additional level of security in case your API key leaks, the key gets used in projects that it should not be or you need to perform this for compliance reasons. Since you cannot have two Admin API keys at the same time, it is highly recommended to use only the newly created write keys and keep the Admin API key out of any application. For highly sensitive applications, we recommend to rotate the keys more often but one year should be the maximum lifetime of the key.

API Keys in mobile applications

Mobile applications represent significant security risks to your API keys, and the inflexibility of mobile applications make secure operations more difficult.

API keys should not be hardcoded in the shipped mobile applications; they should always be dynamically fetched from the application backend. The reason behind this recommendation is that users might not update your application as often as it would be desired. When you then rotate your API key as part of the security workflow or the key leaks and you need to revoke it, the installed application stops working.

It is also important to keep in mind that the application, which might look secured, can be easily opened by existing tools and your API keys extracted from it. Therefore, don’t give your mobile application API keys more privileges than is necessary and use Secured API keys with expiration times.

Content Security Policy

Content Security Policy is a recent addition to the browser security stack. It allows you to define what resources can be loaded, to what domains XHR requests can be performed, if HTTP is allowed and many more. Implementation of Content Security Policy on larger projects is not always easy and with Algolia API clients which abstract a lot of logic it is not even obvious how the Content Security Policy should look.

When you’re implementing Content Security Policy, use the following policy to allow the Javascript API client to work correctly:

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

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

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

HTTP Referers restrictions

The referrer is an HTTP header that is sent by browsers. Like all HTTP headers, it can be spoofed, so you should not 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 requesting with another tool (e.g. cURL). To prevent unauthorized access to your data, e.g. to ensure that each user only sees their own data, we recommend using Secured API Keys.

There is a valid use case for the Referer header, though: Since you can trust browsers to send it with every request, it can be used to restrict the usage of your API key to your own website. This prevents another website from “stealing” your key, e.g. for harvesting ad clicks with your own data. As stated above, this does not prevent them from scraping the data with other tools, though. To mitigate that risk, you can restrict which HTTP referers you will accept (as discussed immediately below), and/or you can rate limit API keys.

Authorized HTTP Referers

You can define a list of referers authorized to call the API with a key. If not specified or empty, it will default to any referer. Referers can be targeted by matching a prefix or a suffix using the * character. A few examples:

• https://algolia.com/* will restrict access to all referers starting with https://algolia.com
• *.algolia.com will restrict access to all referers ending with .algolia.com
• If you want to allow access for the full domain algolia.com, you can use *algolia.com/*

Blocking IPs

If you experience a sudden increase in query operations that cannot be explained by normal usage, then you may have something wrong with your implementation. It is also possible that certain users or bots are sending an abnormal amount of requests to your site. If this is the case, you may want to block IP addresses that are excessively triggering operations. Note: this can’t be done through Algolia. It must be done in your search implementation by preventing searches from the responsible IP addresses.