Skip to content

CWE-259: Hard-Coded Password

Overview

This issue was identified during dynamic (DAST) scanning based on observed authentication behavior and runtime responses indicating acceptance or exposure of fixed credentials.

Analyzing the Dynamic Scan Result

What the DAST Scanner Found

When reviewing your security scan results, you'll see:

HTTP Request Details

  • URL and endpoint that triggered the finding
  • HTTP method (GET, POST, etc.)
  • Query parameters or form data with test payloads
  • Request headers and body content

HTTP Response Evidence

  • Response showing the vulnerability manifestation
  • Evidence of improper credential handling or fixed-credential acceptance
  • Runtime behavior indicators

Attack Vector

  • Which parameter or input is vulnerable
  • Type of authentication abuse possible
  • Context where the vulnerability appears

Mapping DAST Findings to Source Code

DAST cannot directly identify hard-coded secrets in source; this mapping step helps trace observed runtime credential behavior back to likely implementation causes.

Find the Vulnerable Endpoint

Search for fixed or embedded credentials:

# Search for passwords in code
grep -ri "password.*=" src/
grep -ri "pwd.*=" src/
grep -ri "passwd" src/
grep -r "secret" src/
grep -r "api_key" src/

Locate Credential Usage

Common patterns to search for:

  • Database connections: Connection strings with passwords
  • API keys: Hard-coded in source files
  • Service accounts: Default/hard-coded passwords
  • Configuration: Passwords in code (not env vars)
  • Test credentials: Left in production code

Find Hard-Coded Values

Search for literal credentials:

# Find hard-coded values
grep -r "password.*=.*['\"]" src/
grep -r "mysql://.*:.*@" src/
grep -r "postgres://.*:.*@" src/

Trace to Vulnerable Operation

Look for hard-coded credentials in:

  • Database connections: db.connect('user:password@host')
  • API authentication: api_key = "hardcoded123"
  • Service accounts: Default admin passwords
  • SMTP/email: Email server credentials
  • External services: AWS keys, API tokens in code
  • Output rendering or response construction
  • Authentication or authorization checks

Remediation

Core Principle: Never embed secrets in application artifacts (source, images, configs, or client code); secrets must be injected at runtime from a dedicated secrets store and treated as replaceable, least-privilege credentials.

→ For comprehensive remediation guidance, see Static CWE-259 Guidance

Verification and Follow-Up Testing

After applying the fix:

Reproduce the Vulnerability

# Search for hard-coded credentials
grep -ri "password" src/ | grep -v ".git"
grep -ri "api.*key" src/
grep -r "mysql://" src/

# Check for exposed secrets
git log -p | grep -i "password"

Verify the Fix

  • Confirm no passwords in source code
  • Verify credentials loaded from environment variables
  • Check secrets management solution used (Vault, etc.)
  • Ensure configuration files not committed
  • Test that .env files are in .gitignore
  • If credentials can be rotated without code changes and no fixed secrets are accepted at runtime, this class of weakness has been eliminated.

Test Edge Cases

# Check for various credential patterns
grep -ri "password.*=.*['\"]" src/
grep -ri "secret.*=.*['\"]" src/

# Database connection strings
grep -r "://.*:.*@" src/

# API keys
grep -ri "AKIA" src/  # AWS keys
grep -ri "sk_live_" src/  # Stripe keys

# Check git history
git log --all --full-history -p | grep -i "password"

# Or use browser DevTools Network tab to copy as cURL

Re-run DAST Scanner

Run your dynamic scanner again on the fixed endpoint to confirm remediation.

Additional Resources