Database connection strings in the open: Postgres, MySQL, MongoDB
One line, total access
A database connection string looks innocent — it is just a URI. But unpack it and it contains everything required to connect to your database directly: the host, the port, the username, the password, and the database name. A Postgres string like postgresql://user:password@db.example.com:5432/dbname, a MySQL mysql://..., a MongoDB mongodb+srv://user:password@cluster0.example.net/... — each is the master key to your data in a single line.
That density is exactly what makes an exposed connection string so serious. There is nothing else for an attacker to figure out.
How they end up exposed
Connection strings leak through the same quiet paths as any secret, with a few favourites:
- In client-side code. A connection string used anywhere the browser can reach it — a frontend bundle, an inline script — is fully readable. Databases are meant to be talked to from your server, never directly from the browser, so a string in client code is both a leak and an architecture mistake.
- Committed to a repository. Pasted into a config file, a
.env, or a settings module and committed. If that repo is or becomes public, the string is one search away. - Served as a file by URL. A
.envor config file deployed into a public folder, reachable by a predictable path. - In logs and error pages. A verbose error or a stack trace that prints the connection string when a query fails.
Why a leaked string is worse than many secrets
Some leaked keys are scoped — a publishable key, a read-only token. A database connection string usually is not: it is often a full-access account that can read, modify and delete everything. And databases are frequently reachable over the network, so an attacker with the string may not need anything else to connect straight in. Bots scan for database URI patterns precisely because the payoff is so direct.
How to keep them safe
- Never put a connection string in client-side code. The browser should talk to your backend; only your backend talks to the database.
- Keep it in server-side configuration — environment variables or a secrets manager — not in committed files.
- Do not log it. Make sure errors and stack traces never render the connection string.
- Lock down the database itself. Restrict network access so the database is not openly reachable from the whole internet, and use a least-privilege account rather than an admin one for the app.
- Rotate on any exposure. If a string was ever reachable, change the password immediately and review the database for access you do not recognise.
The honest reality
This happens to careful teams. A connection string gets pasted somewhere convenient during setup, the app works, and the string is forgotten in a file that later ships. The exposure is silent until someone — or some bot — finds it.
Check what your site exposes
You cannot eyeball your bundles and config files for a buried connection string. An automated scan reads your pages, scripts and well-known config paths the way a bot would and flags database credentials that are reachable. Scan your site and confirm your database keys are not sitting in the open.