Recommended customer security best practices

This page provides an overview of security practices and recommendations for mabl customer's use of the mabl system.

Mabl Link

The mabl Link agent creates a secure tunnel between customer networks hosting internal applications and tests running in the mabl cloud. Mabl secures this tunnel so that only traffic generated by containers and virtual machines running your tests is proxied over it. All traffic from tests using a given Link agent is proxied through the node(s) running that Link agent. Given this, we recommend you follow the Principle of Least Privilege for the machines running the Link agent and give them access only to necessary applications and services.

Test data and artifacts

Test artifacts and data are stored securely in mabl using workspace specific encryption keys and protected by robust information security policies and procedures. However, mabl is NOT currently HIPAA or PCI certified. We recommend all customers use test accounts and data, even when testing in production. This is especially important if your application collects any sensitive patient or credit card data.

Credentials and other secrets

In order to execute end to end tests in the cloud, it is typically necessary to store credentials and/or other sensitive secrets in mabl. To provide additional security, mabl encrypts certain sensitive fields with a customer specific encryption key before writing them to our database. The set of encrypted fields includes credentials, environment variables, and custom HTTP headers. However, in order to facilitate local test replay, these fields are currently available to any member of the workspace.

To minimize the impact of any exposed credentials/secrets mabl recommends the following best practices:

• When testing in environments that contain customer data, such as production, use test accounts and credentials.
• If your system supports it, only use secrets shared with mabl for running tests in mabl. For example, if you can generate API keys used to access your system, give mabl its own API keys that are not used by anyone else or any other processes.
• For users with a large number of users and applications, we recommend using separate workspaces to isolate access to credentials and secrets. At the current time, mabl does not have support for restricting access to specific credentials by individual users or roles

📘

Access to credentials and API keys

Credentials can be created, viewed and modified by editors and owners of a workspace. API keys can only be created, viewed, and modified by workspace owners.