Security Best Practices
On this page
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.
Secure your Admin API Key
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.
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.
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:
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.
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.
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
A few examples:
https://algolia.com/*will restrict access to all referers starting with https://algolia.com
*.algolia.comwill restrict access to all referers ending with .algolia.com
- If you want to allow access for the full domain algolia.com, you can use
If you notice a sudden increase in query operations that cannot possibly be explained by normal usage, then there is probably something wrong either with your implementation or with something that is not your fault, such as google bots. If this is the case, you may want to block the ip address triggering all the operations.