Guides / Security / Security best practices

Shared Responsibility

Security is one of our primary concerns. We strictly follow the works of the security research community to keep on improving the security of your Algolia data and applications. But much as we strive to keep your data secure, some things remain out of our control.

As with any other cloud service, security is a shared concern between Algolia and its customers. While we take full responsibility for the security of our infrastructure, you’re in charge of making sure you follow our recommended practices to avoid exposing your data and account.

What Algolia is responsible for

We’re responsible for ensuring the security of our service. It includes securing our physical and virtual infrastructure, remaining compliant with our many standards and certifications, and implementing state of the art security practices such as API keys with ACL, two-factor authentication, as well as SAML SSO and AES256 encryption for our Enterprise users.

We also make sure that our providers follow strong security guidelines as well, and continuously train our employees on the subject. Each new Algolia team member goes through mandatory security training, which we renew yearly.

Generally speaking, consider that Algolia is responsible for the security of the service: it’s our responsibility to secure everything we author and provide you. This includes our entire ecosystem: our search engine and infrastructure, but also our other APIs, our official open-source API clients, framework integrations and extensions, UI libraries, Crawler, and the Algolia dashboard.

What you’re responsible for

Algolia is responsible for defects in the service, but not for the consequences of any behavior or usage that goes against our recommended practices, or doesn’t follow our documentation for a given use case. You’re responsible for how you use Algolia, and for the data you send.

For example, we provide you with two-factor authentication, but it’s your responsibility to activate it and make sure that all your team members do as well. Same goes with your data: we offer features to ensure you can keep sensitive data from unauthorized users, but you must make sure to use these features appropriately, and test them on your end.

Securing your API keys

We provide you with predefined API keys and allow you to create new ones with fine-grained access-level. While we make sure to generate these keys securely, not to leak the ones that we store, and to encrypt the virtual ones properly, 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 we strongly recommend using environment variables to inject your keys rather than hardcoding them in your code. It 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 we recommend injecting your API keys with environment variables, we aren’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.

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.

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 we can’t help you if they perform irreversible operations. For those reasons, we recommend that you 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.

Sensitive information

We implement state-of-the-art practices when it comes to ensuring that your data is safe and isolated from other Algolia customers. We also provide many ways for you to prevent access from unauthorized users, such as Secured API keys or unretrievableAttributes, along with Algolia Vault for Enterprise users. When dealing with sensitive information, we strongly recommend you use those 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. They 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.

Control level

When it comes to shared responsibility within a cloud service, you can consider three levels of control. These help you understand what falls under our responsibility, and what’s on you.

Inherited controls

These are what you inherit from Algolia, and can’t change. For example, when you create an Algolia application, we provision it on our platform, running in one of our regions. This isn’t something you can control or change (e.g., you can’t deploy an Algolia application on-premise). Therefore, we’re fully responsible for those controls.

Shared controls

These are what comes from Algolia, but you gain control over. Shared controls have shared responsibility. For example:

  • We provide and store API keys and let you generate new ones. We’re responsible for how we store your keys on our end and for properly encrypting the virtual ones. However, you’re responsible for how you store and use your keys on your end.
  • We offer and maintain open-source API clients and UI libraries that we strongly recommend you to use. We’re responsible for following best practices, fixing security issues, and letting you know about potential vulnerabilities. However, you’re responsible for upgrading to the latest versions of our libraries, making sure that the environment in which you run them is secure as well, and that it supports the features we implement (e.g., HTTPS).
  • We train Algolia employees and raise awareness around security internally, but you’re responsible for training your teams.

User controls

These are what solely depends on your use case and application requirements, and therefore, is your full responsibility. For example, you’re responsible for how you name your indices, for what data you index into Algolia and for how you control access to this data, or for which team members you invite to your application and with what access level.

Did you find this page helpful?