Connection String Exposed
Database connection URLs containing usernames and passwords are hardcoded in source code, making credentials accessible to anyone with repo access.
How It Works
Developers often hardcode database connection strings directly in source files or configuration that gets committed to version control. These strings contain the full URI including username, password, host, and database name. Once pushed to a repository — even a private one — the credentials become accessible to every collaborator and persist in git history forever. Attackers who gain any level of repo access can extract these credentials and connect directly to the database. Automated scanners on GitHub constantly search for exposed connection strings in public repositories.
const { PrismaClient } = require('@prisma/client');
const prisma = new PrismaClient({
datasources: {
db: { url: 'postgresql://admin:s3cretPass@db.example.com:5432/myapp' }
}
});const { PrismaClient } = require('@prisma/client');
const prisma = new PrismaClient({
datasources: {
db: { url: process.env.DATABASE_URL }
}
});Real-World Example
In 2022, Toyota disclosed that a subcontractor accidentally published source code containing database credentials to a public GitHub repository for nearly five years, potentially exposing data of 296,019 customers including email addresses and customer management numbers.
How to Prevent It
- Store all connection strings in environment variables, never in source code
- Add .env files to .gitignore before the first commit
- Use secret scanning tools like GitGuardian or GitHub Secret Scanning
- Rotate credentials immediately if they were ever committed to version control
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
Database Backup Exposed
highDatabase dump files (.sql, .dump, .bak) committed to the repository expose the entire database schema and data, including user credentials and sensitive records.
Raw Queries in ORMs
highUsing raw SQL methods like Prisma's $queryRaw or Sequelize's query() with string interpolation bypasses the ORM's built-in SQL injection protection.
Unsafe Deserialization
highDeserializing untrusted data with libraries like node-serialize or Python's yaml.load allows attackers to execute arbitrary code on the server.
Exploitable N+1 Queries
lowUnbounded relation expansion in ORM queries allows attackers to trigger thousands of database queries with a single API request, causing denial of service.