Security best practices

Security is a shared responsibility between Algolia and you, the developer. Follow these best practices to avoid exposing your data and your Algolia account.

Two-factor authentication

All users with access to your account should enable two-factor authentication. You can use your preferred authenticator app, such as Google Authenticator, Microsoft Authenticator, or Twilio Authy.

To enable two-factor authentication, follow these steps:

1. Go to the Algolia dashboard.
2. On the left sidebar, select Settings.
3. Click Account details.
4. In the Two-factor authentication section, click Enable and scan the barcode with your authenticator app.
5. Securely save your recovery codes.

If you lose access, see How to reset two-factor authentication (2FA)

Secure your API keys

Algolia has a few predefined API keys and lets you create new keys with detailed access control lists (ACL). Set restrictions on keys to limit user access and prevent data crawling. Algolia securely generates and encrypts keys, but you must handle them responsibly. Don’t use write-access keys in frontend code or mobile apps, and use environment variables for API keys in your code instead of hardcoding them. This extra security layer helps if your source code is exposed.

Be careful when using third-party services. When a third-party service, such as a continuous integration (CI) service, has a security incident, your Algolia API keys might leak into the public. Follow best practices and immediately change your keys when a security incident occurs.

Keep your admin API key confidential

Your account’s admin API key gives access to everything in your account, including all your indices. Keep your admin API key confidential and never use it in production.

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

Rotate your API keys regularly

Regenerate all your API keys at least once a year. This provides extra security if an API key leaks, is misused, or is required for compliance purposes. For sensitive apps, rotate your keys more often. One year should be the maximum lifetime of an API key.

Use secured API keys in mobile apps

Don’t hardcode API keys in mobile applications. When you need to update your API keys, users need to update your app on their devices, or they won’t be able to search on your site. But often, users can’t update your app as often as you’d like.

That’s why you should fetch restricted API keys dynamically from your app’s backend.

On top of that, there are tools that scrape information from mobile apps, including any hardcoded credentials. Add only the necessary permissions to your app’s API keys with expiration times.

Separate your development and production environments

If you’re using different Algolia applications for development and production, you automatically use different API keys.

If you’re using a single Algolia application with development and production indices, use different API keys for each index.

Team management

When you invite team members, only give them access to the parts of your app that they need.

Remove access from members who leave your team

Algolia can’t help you if team members perform irreversible operations in your Algolia application. That’s why it’s best to invite team members only with their professional email addresses, so you can safely revoke their access if needed.

Use a shared email address for the account owner

If you’re using an individual email address for the account owner, your team might lose access if this person leaves or becomes unavailable. It’s better to use a shared company email address for the owner of your Algolia application.

If you want to change the account owner, see How to transfer ownership of an account to someone else?

Sensitive information

Algolia follows best practices to ensure that your data is secure and isolated from the data of other Algolia users. To prevent access from unauthorized users, Algolia provides these features:

• Secured API keys with access restrictions
• unretrievableAttributes
• Algolia Vault

Follow these steps when dealing with sensitive information:

• Don’t use sensitive data in metadata. Some metadata is stored in logs.
• Don’t use sensitive information in an index name. Index names are public, because they appear in network requests.
• Don’t use personally identifiable information as userToken parameter in search requests.

Algolia internal logs

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.

The data is stored in the region you specified when choosing your Algolia plan. For more information, see Extending the retention period of the analytics data.

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 https://*.algolia.io;

If you’re using InstantSearch with insights set to true and you’re letting the library load search-insights for you, make sure to add https://cdn.jsdelivr.net in your list of trusted sources for JavaScript.

1
script-src https://cdn.jsdelivr.net/

HTTPS security practices

Algolia uses HTTPS for all API requests.

HTTP referrers restrictions

Browsers send referrer source URLs through the Referer or the Origin HTTP header. Like all HTTP headers, it can be spoofed. For example, you can change the Referer header with curl. Use secured API keys to prevent unauthorized access to your data.

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 scrape 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 restrict the referrers that are allowed to make API requests with a given API key. By default, any referrer is allowed.

Target referrers by matching a prefix or 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/*.

Block IP addresses

If you see an unexpected increase in search operations, first check if your search implementation is working as expected.

If you suspect bots or users sending too many requests to your site, consider blocking specific IP addresses from accessing your website (outside of Algolia).

Further reading