A database URL is not just an address; it usually embeds the username and password. If Cursor hardcoded a connection string and it reached a commit, treat those credentials as compromised. Rotate the database password first, then move the URL to an environment variable.
Why it's a problem
A connection string like postgres://user:password@host/db hands an attacker direct database access, no application in the way. In a public repo it is scraped within minutes, and from there someone can read, modify, or delete your data or run up costs on a managed database.
How to fix it, in order
- 1Rotate the database credentials. Change the database user's password (or rotate the credential your provider issues). This invalidates the exposed connection string.
- 2Check for unauthorized access. Review database logs and your provider's activity for connections or queries you did not make.
- 3Purge the string from git history. Remove it with filter-repo or BFG and force-push; rotation in step one is what actually protects you.
- 4Move the URL to an environment variable. Read it from process.env, confirm the .env is gitignored, and add .env to .cursorignore so Cursor does not index it.
Why Cursor does this
Wiring up a database is a common task, and pasting the full connection string inline is the quickest way to get a working connection. Cursor also indexes your workspace, so a URL in a .env that is not in .cursorignore can end up in a prompt as well.
Stop it happening again
Keep the connection string in a gitignored .env, add .env to .cursorignore, and add a gitleaks pre-commit hook so a hardcoded connection string fails the commit. Rotate credentials the moment a string is exposed.
The quick fix
- Rotate the database password immediately.
- Check database logs for unauthorized connections.
- Purge the connection string from git history.
- Move the URL to a gitignored .env and add it to .cursorignore.