T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:124
- Finding
- Predictable Database Credentials in a Production Configuration Template<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 124–126 **Vulnerability Type**: Insecure default credentials **Risk Level**: Medium ### Vulnerable Code ```yaml url: ${DATABASE_URL:jdbc:postgresql://localhost:5432/mydb} username: ${DATABASE_USERNAME:postgres} password: ${DATABASE_PASSWORD:postgres} ``` ### Technical Analysis The configuration is explicitly presented as an `application.yml` production template but supplies the predictable `postgres/postgres` credential pair when the corresponding environment variables are missing. This is a fail-open configuration: an incomplete deployment can start successfully with known credentials rather than failing because a required secret was not provided. It also conflicts with the Skill's own recommendation not to hardcode secrets. The documentation itself does not connect to a database or expose an existing deployment. Exploitation becomes possible when a user copies this template into an application without replacing or removing the fallback values. ### Attack Path 1. A developer copies the production configuration template into a Spring Boot application. 2. The deployment omits `DATABASE_USERNAME` or `DATABASE_PASSWORD`. 3. Spring resolves the missing values to `postgres` and `postgres`. 4. The PostgreSQL service is exposed to an attacker through the network or another compromised workload. 5. The attacker authenticates using the documented credential pair. 6. The attacker obtains all database permissions assigned to that account. ### Impact Assessment A successful attacker can exercise the privileges of the configured PostgreSQL account. Depending on how that account is provisioned, this may permit reading, modifying, or deleting application data, changing database objects, and disrupting service availability. If the default `postgres` role retains administrative privileges, the impact can extend to other databases and roles in the same PostgreSQL instance. This issue does not in ...[truncated 196 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions Remove all production credential defaults and require explicit secret injection: ```yaml spring: datasource: url: ${DATABASE_URL} username: ${DATABASE_USERNAME} password: ${DATABASE_PASSWORD} ``` Apply the following hardening measures: 1. Configure startup validation so the application fails when any required database variable is absent. 2. Retrieve credentials from a managed secret store rather than source-controlled configuration. 3. Use a dedicated application database role instead of the PostgreSQL administrative role. 4. Grant only the minimum required schema and data permissions. 5. Restrict database ingress to authorized application workloads. 6. Rotate any default credentials that may already have been deployed. 7. Add CI/CD policy checks that reject production configuration containing fallback passwords or known credential pairs. ]]>