Currently, the Checkly UI does not provide a secure way to handle secrets, such as tokens and API keys, in an obscured manner. This poses potential security risks, as sensitive information is visible in clear text to anyone with access to the respective Checkly checks or channels.

Use Cases

Checkly Check: Using a Bearer Token for Authentication

• When adding an "Authorization" request header, users typically input a value like "Bearer MY_TOKEN".

• After saving, the token remains visible in clear text within the UI, exposing it to anyone with access to the check configuration.

• A more secure approach would allow the user to define the Bearer token once, after which the UI would obscure the token, displaying only a masked version (e.g., "Bearer *****").

Checkly Channel - Webhooks:

• Users may/have to include tokens in the request body (e.g., "routing_key" for PagerDuty).

• Similar to the first use case, the token remains visible in clear text after being added, creating a security risk.

• A secure handling mechanism should obscure such sensitive information after initial input, ensuring that tokens are only displayed in a masked format.

Feature Request:

I would like to request a feature that allows for the secure handling of secrets within the Checkly UI. Specifically:

• Obscuring tokens and other sensitive data after they have been entered. This would ensure that such information is not visible in clear text after initial setup.

• Providing an option to update or replace secrets securely without exposing them in the UI.

This enhancement would greatly improve the security of handling sensitive information in Checkly, aligning with best practices for managing secrets.

Notes

• variables can be “locked” but are considered only for unsensitive data. The description in the UI states the following

Variables can be viewed after creation and are used for non-sensitive configuration data.