Database Credential Exposure

Description

Database credential exposure occurs when connection strings, usernames, and passwords used to authenticate to database servers are stored in cleartext or in locations accessible to unauthorised parties. CWE-312 covers the storage of sensitive information without encryption, and this class of vulnerability is one of the most direct paths to total data compromise available to an attacker.

Credentials end up exposed through several predictable routes: hardcoded values in application source files or version control history, .env files deployed to public web roots, cloud storage buckets with overly permissive ACLs, unencrypted configuration management databases, or plaintext values in application logs.

Under A02:2021 — Cryptographic Failures, the OWASP Top 10 specifically calls out credentials transmitted or stored without encryption. Even when encryption is nominally present, weak key management — such as storing the encryption key alongside the ciphertext — renders the protection useless.

How It Works

The most frequently seen exposure paths in penetration tests include:

Hardcoded in source or committed to Git:

# Committed to a public GitHub repository
DB_HOST = "prod-db.internal.example.com"
DB_USER = "app_user"
DB_PASS = "S3cur3P@ssw0rd!"

An attacker searching GitHub with org:example "DB_PASS" or using truffleHog against the repository history will find this credential even if the file was edited in a later commit.

Exposed .env file on a web server:

GET /.env HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
DATABASE_URL=mysql://admin:hunter2@prod-rds.us-east-1.rds.amazonaws.com:3306/appdb

Cloud metadata service leakage — an SSRF vulnerability targeting http://169.254.169.254/ on AWS can return IAM role credentials. If the application then uses those credentials to retrieve secrets from Parameter Store or Secrets Manager without rotation, a single SSRF becomes a full database credential compromise.

Unencrypted backup files — database dump files (mysqldump, pg_dump) stored on S3 buckets without server-side encryption and with public read ACLs expose both schema and all stored credentials simultaneously.

Impact

• Full data exfiltration — direct database access allows bulk download of all customer records, PII, payment data, and proprietary information.
• Data destruction — an attacker with write access can truncate or drop tables, causing complete service outage and unrecoverable data loss.
• Lateral movement — database servers often sit on internal network segments; compromised credentials expose other systems reachable from the database host.
• Privilege escalation — administrative database accounts may have operating-system-level access via xp_cmdshell (SQL Server) or COPY … FROM PROGRAM (PostgreSQL).
• Compliance violation — exposure of credentials providing access to regulated data (PII, PHI, PCI) triggers mandatory breach notification obligations.
• Supply chain impact — in multi-tenant SaaS architectures, a single shared database credential exposure can affect all tenants simultaneously.

Detection

1. Scan version control history — run truffleHog or gitleaks against the full repository history, not just the working tree, to surface secrets deleted in later commits.
2. Probe common configuration file paths — request /.env, /config.php, /database.yml, /application.properties, and /appsettings.json and check for 200 responses containing connection strings.
3. Audit cloud storage bucket permissions — use aws s3 ls s3://bucket-name --no-sign-request to test for unauthenticated read access; check for backup dumps, configuration archives, and deployment packages.
4. Review application logs — search centralised logging (Splunk, ELK, CloudWatch) for connection string patterns (jdbc:, mongodb://, postgres://) that indicate credentials being written to log output.
5. Test SSRF to cloud metadata — probe SSRF vectors with targets pointing to http://169.254.169.254/latest/meta-data/iam/security-credentials/ to determine if application credentials are retrievable via server-side requests.

Remediation

Use a secrets manager. Store database credentials in AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Inject them at runtime via environment variables or IAM-authenticated API calls — never commit them to source control.

Enable automatic rotation. AWS Secrets Manager and similar products support automatic rotation of RDS credentials without application downtime. Enable rotation with a maximum 30-day interval.

Restrict database network access. Database servers should never be reachable from the public internet. Use security groups, VPC peering, or private endpoints so that stolen credentials cannot be used without network access to the database segment.

Add pre-commit secret scanning. Integrate gitleaks into CI to block any commit containing credential patterns before they reach a remote repository.