Protect the credentials used in testing

Purpose of this Article

This document primarily discusses the importance of testing credentials, the risks associated with them, and the measures taken by Testany to ensure their security.

Understanding Data at Risk: Testing Credentials

What Testing Credentials Are

Definition:

Test credentials are credentials that verify the identity and authority of the caller as required by the software service being tested and are used for the execution of test cases on the Testany platform. The credentials for obtaining test cases and executing test pipelines are also test credentials, but their protection measures are not discussed in this article.

Types of Testing Credentials:

This may include API keys, test accounts, tokens, and other forms of credentials used during the testing phase.

The Importance of Protecting Testing Credentials

Role of Testing Credentials in Software Testing

Testing credentials play a crucial role in the software testing process. In a simulated environment, they help replicate real-world scenarios without affecting actual production data or exposing real user information.

These credentials enable testers to validate and verify various features of the application, such as its ability to handle authentication, user roles, and permission levels. Additionally, they help testers identify possible loopholes and vulnerabilities within the authentication system that could be exploited in a real-world scenario. This level of testing is critical in maintaining the robustness, security, and reliability of the software.

Moreover, testing credentials are used to access different testing environments. For instance, these can be used to access QA (Quality Assurance), UAT (User Acceptance Testing), and staging environments that closely mirror the production environment but are meant for testing and development purposes. In this way, testing credentials help facilitate effective testing while minimizing the risk of accidental changes or breaches in the live environment."

Potential Consequences of Compromised Testing Credentials

Compromised testing credentials can lead to a number of damaging consequences, including:

1. Unauthorized Access to Testing Environments: If testing credentials are compromised, unauthorized users may gain access to the testing environments. They can tamper with test results, introduce vulnerabilities, or even disrupt the testing process.
2. Exposure of Sensitive Development Data: Testing environments often contain sensitive data related to the software under development, including new features, proprietary algorithms, or unpatched vulnerabilities. A breach can lead to the leakage of this sensitive information.
3. Security Vulnerabilities: A compromised testing environment can be a stepping stone for attackers to infiltrate other interconnected systems. With the gained access, they may attempt to escalate privileges or exploit any found vulnerabilities, leading to more significant security breaches.
4. Reputational Damage: If a security breach becomes public, it can lead to reputational damage. Customers and partners may lose trust in the company's ability to protect not only its production environment but also its testing environment.
5. Legal and Compliance Issues: There may be legal and compliance implications, especially if the breach leads to the exposure of sensitive or personally identifiable information (PII). The company could face penalties or lawsuits for failing to adequately protect its systems.

It's vital to protect testing credentials to prevent these potential consequences. This means adopting robust security measures, including secure credential storage, role-based access control, and regular audits and monitoring.

The solutions to protect credentials used in Testing

In order to provide comprehensive protection for the credentials required in testing, Testany has introduced the "Trusted Credential Safe" solution.

There are two key components in this "Trusted Credential Safe" solution:

a) A safety credential CRUD product provided by an IaaS vendor (e.g., AWS Secrets Manager, Azure Key Vault)

b) A safety method to exchange credentials and references between Testany Platform and credential safe provided by the IaaS vendor.

At present, the Testany Platform supports two different ways of deploying the Trusted Credential Safe solution:

a) hosted by Testany, or

b) using the credential safe service under the user's own IaaS account.

For administrators who need to set up Credential Safes and manage credentials, see Managing Test Credential.

Using Credentials in Your Test Code

The recommended workflow is now: add a Secret row under Environment variables in the test case. Before execution starts, the platform resolves that reference automatically and injects the secret value into the normal runtime environment.

Step 1: Configure a Secret in Environment variables

Open the test case detail page, click Edit, and find Environment variables.

Add a new row, set Type to Secret, then select:

• Workspace
• Credential Safe
• Credential

Also fill in the row Key. This Key is the display name of the secret reference inside the test case, which helps with case configuration, bulk operations, and reviews.

After saving, the platform stores only the structured reference. It does not store or display the raw secret value inside the test case.

How the Runtime Exposes This Secret

Before the test actually starts, the trusted runtime resolves the configured Secret reference and writes the real credential value into the execution environment.

For your test code, the practical result is:

• the Key of the Secret row becomes the environment variable name visible during execution
• you read it exactly like a normal environment variable
• you do not need to assemble safe_key / credential_key yourself
• you do not need to call TESTANY_SECRETS_SERVICE manually

For example, if the Key of the Secret row is CLIENT_SECRET, then your test reads CLIENT_SECRET during execution.

Secret status meanings

After saving, the platform returns a status for each Secret row. Common values are:

• valid: the reference exists and the current case is allowed to use it.
• blocked: the reference exists, but the current case owner and/or visibility no longer qualifies for it.
• invalid: the reference cannot be resolved, typically because the workspace, safe, or credential no longer exists, or the reference is incomplete.

Step 2: Read It Like a Normal Environment Variable

Once execution starts, the secret appears in the runtime just like a normal environment variable.

That means you should read it with the standard environment-variable access pattern of your framework.

Sample Code

Postman

JavaScriptCopy
const clientSecret = pm.environment.get("CLIENT_SECRET");

if (!clientSecret) {
  throw new Error("CLIENT_SECRET is missing");
}

Python

PythonCopy
import os

client_secret = os.getenv("CLIENT_SECRET")
if not client_secret:
    raise RuntimeError("CLIENT_SECRET is missing")

Java

JavaCopy
String clientSecret = System.getenv("CLIENT_SECRET");
if (clientSecret == null || clientSecret.isBlank()) {
    throw new IllegalStateException("CLIENT_SECRET is missing");
}

Playwright (TypeScript)

TypeScriptCopy
const clientSecret = process.env.CLIENT_SECRET;

if (!clientSecret) {
  throw new Error('CLIENT_SECRET is missing');
}

JMeter

In JMeter, you can read it in a JSR223 Sampler Groovy script the same way you read a normal environment variable:

GroovyCopy
def clientSecret = System.getenv("CLIENT_SECRET")
if (!clientSecret) {
    throw new IllegalStateException("CLIENT_SECRET is missing")
}

Best Practices and Recommendations to protect your credentials

Protecting credentials during software testing is critical to maintain the integrity and security of the software being tested. It involves not only security measures from the tool (Testany Platform) but also relies on users' adherence to standardized and secure operations and comprehensive security processes. Below are some practices and processes we strongly recommend users to follow to protect credentials.

Admin:

1. Principle of Least Privilege (PoLP)

• Access Control: Ensure that the credentials provided for testing have the minimum necessary permissions to perform the test. This limits the impact in case of credential compromise.
• Regular Audits: Conduct regular audits of permissions associated with each credential to ensure they adhere to this principle over time.

2. Rotate Credentials Regularly

• Automated Rotation: Use automated tools or cloud services capabilities to rotate credentials periodically. This reduces the window of opportunity for an attacker to exploit stale credentials.

3. Monitor and Audit Access

• Access Logs: Enable logging of Credential Safe for all access to sensitive information and credentials. Regularly review these logs to detect unauthorized access attempts or suspicious activities.
• Alerts: Set up alerts for abnormal access patterns or security incidents related to credential usage.

4. Cloud IAM with Trusted Credential Safe

• Access Control: Using the cloud provided IAM solution to connect with the Trusted Credential Safe

User:

1. DO NOT hardcode any sensitive data in either test scripts or test meta. Strictly store any sensitive data (for example credentials or PII) in the Credential Safe provided by your organization, and reference it from the test case through Secret rows. During execution, the runtime injects those values into environment variables automatically, which keeps sensitive data isolated from the codebase and reduces the risk of accidental exposure.
2. Rotate Credentials Regularly

• Automated Rotation: Use automated tools or cloud services capabilities to rotate credentials periodically. This reduces the window of opportunity for an attacker to exploit stale credentials.

3. Use Dedicated Test Accounts

• Separation from Production: Create dedicated accounts for testing purposes that are separate from production accounts. This ensures that any compromise does not affect production data or services.