secret.connection_string
A database or broker URL with a password embedded in it appears in the text.
What it looks at#
A URL of the form scheme://user:password@host for postgres, postgresql, mysql,
mariadb, mongodb, mongodb+srv, redis, rediss, amqp, amqps, mssql,
sqlserver, clickhouse and libsql, with a non-empty password. No gitleaks rule covers
these, so this is our own pattern. The reported span is the password only.
Placeholders and stock development defaults are skipped: <password>, shell-variable references,
{{ ... }}, xxxx, REDACTED, *****, a password equal to the user name
(postgres:postgres, guest:guest), and common defaults such as password, changeme,
root, admin, test. A URL with no password (postgres://app@db/app) is not a finding.
Why it matters#
A connection string is host, user and password in one line. Pasted into a ticket, a chat or a log, it is everything needed to connect, and it often reaches a production database that is not behind a VPN.
What to do#
High severity. Rotate the database password, then check connection logs for logins you do not recognise. Keep connection strings in a secret manager or environment, and reference them by name in tickets and chat.
Example#
curl -s -X POST https://api.stormdoor.dev/v1/secrets \
-H "Authorization: Bearer sk_live_..." \
-H "content-type: application/json" \
-d '{"text":"DATABASE_URL=postgres://app:Xk9sLm2Qw7Vb@db.internal:5432/app"}'The response carries one secret.connection_string finding. With postgres://app:password@db
it returns verdict: "clean".