DSN Security & Connection String Secrets
debt(d5/e5/b5/t5)
Closest to 'specialist tool catches it' (d5) — tools like trufflehog, gitleaks, and semgrep (from detection_hints.tools) are specialist secret-scanning tools that can detect hardcoded credentials in code or committed .env files, but they require deliberate integration into CI/CD pipelines rather than being default linter behavior.
Closest to 'touches multiple files / significant refactor in one component' (e5) — while the quick_fix suggests using environment variables and secrets managers, remediation often requires: updating config files, modifying deployment scripts, integrating a secrets manager, rotating compromised credentials, and auditing git history; if credentials were committed, they're permanently compromised requiring full credential rotation across all environments.
Closest to 'persistent productivity tax' (b5) — applies_to shows this affects all PHP contexts (web, cli), and proper secrets management creates ongoing operational overhead: developers need secrets access workflows, CI/CD needs secrets injection, credential rotation must be coordinated, and every new environment or developer requires secrets provisioning; this isn't architectural rework but does impose continuous friction.
Closest to 'notable trap' (t5) — the misconception field explicitly states that developers believe 'environment variables are always secure' when they can leak via process listing, phpinfo() pages, error messages dumping $_SERVER, and debug toolbars; this is a documented gotcha that most developers eventually learn but contradicts the common belief that moving credentials to env vars fully solves the security problem.
Also Known As
TL;DR
Explanation
DSN (Data Source Name) contains host, port, database name, username, and password. Security practices: store in environment variables (not committed .env files), use secrets managers (AWS Secrets Manager, HashiCorp Vault) in production, rotate credentials regularly, use least-privilege DB users (SELECT/INSERT/UPDATE/DELETE only, no DDL for app users), and never log the full DSN. PHP: PDO DSN format 'mysql:host=...;charset=utf8mb4'. Disable phpinfo() in production to prevent config exposure.
Common Misconception
Why It Matters
Common Mistakes
- Hardcoded credentials in PHP source code committed to git
- .env file with credentials committed to git — .env must be in .gitignore
- Database error messages that include the connection DSN
- Root DB user for the application — use least-privilege users
Code Examples
// Credentials hardcoded — in every git clone forever:
$pdo = new PDO(
'mysql:host=db.internal;dbname=production',
'root', // Root user — can DROP entire database!
'password123', // Hardcoded — permanently in git history
);// Credentials from environment — never hardcoded:
$dsn = sprintf(
'mysql:host=%s;dbname=%s;charset=utf8mb4',
getenv('DB_HOST') ?: throw new RuntimeException('DB_HOST not set'),
getenv('DB_NAME') ?: throw new RuntimeException('DB_NAME not set')
);
$pdo = new PDO($dsn, getenv('DB_USER'), getenv('DB_PASS'), [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);
// DB_USER: app_user with SELECT INSERT UPDATE DELETE only (no DDL)