When configuring Web Services and Internet Infrastructure test requests and you need to protect specific data stored in monitoring or load test from unauthorized access, we recommend using our feature called Secure Vault. With Secure Vault, you can store private keys, passwords, and other types of sensitive data in encrypted name-value pairs organized in Crypt containers. Only authorized users with the corresponding permissions in your Dotcom-Monitor account will have access to the Crypt containers.

When to Use Secure Vault

There are two common use cases when Secure Vault might be useful for monitoring setup:

  • Protecting sensitive data in the device settings. For example, if you want to hide sensitive data (PCI, PII) in URL query parameters, or JSON payload, as well as in the reports from users with restricted permissions in your Dotcom-Monitor account.
  • Using the same variables in several monitoring devices. For example, you might need to configure requests to several targets with the same login and password and want to be able to edit the credentials from one place for all devices at once.

Configuring Secure Vault and Device Settings

To start using Secure Vault, you will first need to add a Crypt container and specify name-value pairs for all variables you want to use in encrypted form to set up your monitoring request. You can use Crypt variables to pass any dynamic data in query strings in URL or target address parameters, headers, authentication data, Post Data, etc. Visit the Secure Vault article on our Knowledge Base to learn more about setting up Secure Vault and creating Crypt variables.

To avoid sending sensitive data to unwanted websites, it is advisable to specify a realm of allowed domain names (see Associating Crypt Variables with Specific Domain Names ( Hosts)). If limiting a Crypt variable to specific domains, the Crypt variable value will be passed only to the requests to the specified domains.

Note that if the Use this Variable only for Masked Fields option is checked in Crypt variable settings, the variable value will be masked in the device settings, reports, error statistics details, etc., regardless of the Unmasked Value checkbox state.

Once you have a Crypt variable set up, you can use it to encrypt a request parameter value in your monitoring or load test request settings. To do this follow the steps below:

  1. In the device settings, select or add a new parameter, and in the parameter value field click a gear icon to convert the value to Dynamic.
  2. In the Edit Value window, select Dynamic and specify the parameter value using the following syntax: SecureVault.<Crypt_name>.<Variable_name>
  3. Click Done.

Example: Using Crypt Variables in POST Data

To illustrate how encrypted name-value pairs work within monitoring requests, we will use the example of an HTTP request with encrypted user credentials. For this example, we will create a request to an HTTP test server:

1. First, we need to create a Crypt within Secure Vault and add a variable to store a user password value in it. To restrict the realm of the variable usage to a specific domain, we specify the domain in the Realm field.

2. In the next step, we use the variable from the Crypt in the request header and Post Data to protect a user password from being exposed to unauthorized users within Dotcom-Monitor, as well as any third-party web services.

3. In the screenshots below, you can find the HTTP request body returned from an HTTP test server.

Example: Using Crypt Variables in GET Request

Let’s look at some more examples of using Crypt variables in your HTTP requests.

Pictures below show an example of using a Crypt variable in the HTTP GET request to a dynamic URL. In this case, the endpoint address is hidden for all Dotcom-Monitor account users in the device settings, alert notifications, and report data. Only users with Secure Vault access permissions can see and change the Crypt variable value.

Example: Using Crypt Variables for Basic Authentication

In the next example, Crypt variables are used for Basic Authentication in the HTTP request. The password and username values are stored in the associated Crypt variables and referred to in the related Authentication fields.