When setting up WebView and ServerView type tasks and you need to protect specific data stored in your monitoring devices 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 monitoring of several targets with the same login and password and edit the credentials used for monitoring 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 of our Knowledge Base to learn more about setting up Secure Vault and create 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 as a context variable to specify a request parameter value in your device settings. To do this follow the steps below:

  1. In the Target settings of the device, add a new parameter you are going to send in encrypted form.
  2. Specify the parameter name, point to the related Value field, and click the gear icon to convert the parameter value to context one.
  3. In the Edit Value window, select Dynamic and specify the parameter value using the following syntax: SecureVault.<Crypt name>.<Crypt variable name>
  4. Click Done.

Example Use Cases

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. On 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 initial HTTP request body returned from an HTTP test server.

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

In the following images, you can see an example of using a Crypt variable in the HTTP 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 enough permissions to access Secure Vault can see and change the Crypt variable value.

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.