lowCWE-798A02:2021

Hardcoded Test Data

Test files with hardcoded real email addresses, phone numbers, or production-like credentials can leak PII and create security confusion.

How It Works

Developers often use real-looking or even real data in tests for convenience. If a test file contains a real person's email or a credential that looks like a production key, static analysis tools flag it as a secret exposure, and it becomes unclear whether it's test data or a real leak.

Vulnerable Code
// BAD: test data that looks like or is real sensitive data
describe('User auth', () => {
  it('should login', async () => {
    await login('john.doe@realcompany.com', 'P@ssw0rd123!');
    // real email, real-looking password — confusing and potentially real
  });
});
Secure Code
// GOOD: obviously fake test data using standard test patterns
describe('User auth', () => {
  it('should login', async () => {
    await login('test@example.com', 'test-password-not-real');
    // example.com domain + clearly labeled — no confusion
  });
});

Real-World Example

Multiple bug bounty reports have been submitted for test files containing what appeared to be real credentials. Even when they weren't real, the security team had to spend time investigating — and occasionally they were real production credentials left in from a copy-paste.

How to Prevent It

  • Always use @example.com or @test.invalid for test email addresses
  • Use clearly labeled fake values like 'test-api-key-not-real' for credential fields
  • Configure Gitleaks or similar tools to scan test files with the same rigor as production code
  • Use test fixtures or factories instead of hardcoded values — easier to maintain and clearly fake

Affected Technologies

Node.js

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities