Sharing database credentials safely between development and support
Why database credentials are especially sensitive
A database credential is different from a web application login. It typically provides direct, unmediated access to the data — no application layer, no audit trail within the application, no business logic filtering what can be seen or changed. Someone with a database credential and a client like DBeaver or TablePlus can read every row, export entire tables, modify records, and in many cases drop tables or entire databases.
For this reason, database credentials are among the most sensitive credentials an organisation holds. They deserve exceptional care in how they're created, stored, and — unavoidably sometimes — shared.
When database credentials need to be shared
Despite the sensitivity, there are legitimate scenarios where database credentials must be shared:
Developer onboarding A new developer needs access to the development or staging database to do their work. The credentials need to get from wherever they're stored to the new developer's local setup.
Support and incident response When a production issue requires direct database investigation — data inconsistency, a corruption event, a query to diagnose a bug — a support engineer or developer may need production database access temporarily.
Third-party audits or data migrations An external party may need access to a database for a specific, time-limited purpose: a data migration, a security audit, or an integration project.
The common but dangerous practices
The credentials often end up in:
- A Slack direct message ("here's the DB connection string")
- An email with the subject line "Database access details"
- A comment in a code review
- A shared document that accumulates credentials over time
- Hardcoded in an .env file committed to a repository
Each of these creates a persistent copy of the credential in a location that is not designed for secrets storage and may be accessible to far more people than intended.
A better approach
Separate credentials per environment Development, staging, and production databases should have different credentials. This is fundamental. A developer working on their local environment has no business having production database access. Separate credentials enforce this boundary.
Separate credentials per user where possible Most database systems support multiple users with different permissions. A developer who needs read access to a staging database doesn't need a shared admin credential — they need their own read-only credential. This makes access auditable and revocable per individual.
Use one-time links for credential delivery When credentials genuinely need to be transferred — a new developer needs staging access, a support engineer needs temporary production access — use PassTransfer to deliver them. The credential travels encrypted, is retrieved once, and disappears. Nothing accumulates in Slack or email.
Scope production access carefully For production database access, consider whether it can be granted just-in-time for the specific incident, with automatic expiry, rather than as a persistent credential. Some database management systems and cloud platforms support this natively. If not, treat production credentials as a high-value asset: document every time they're shared, rotate immediately after each use, and maintain a log.
Rotate after each temporary share After a support session, after a contractor finishes their work, after an audit is complete — rotate the database credentials. Don't rely on the other party to have deleted what they received.
The .env file problem
Application configuration files that contain database credentials are a special concern. They should:
- Never be committed to version control (check your .gitignore)
- Never be shared via email or Slack, even as an attachment
- Be transferred to new team members via a secure one-time link
A common practical approach: document which variables belong in .env (with placeholder values) and commit that template, then transfer the actual values to each developer securely when they join.
Conclusion
Database credentials deserve treatment proportional to what they protect. With separate credentials per environment and user, a secure delivery mechanism like PassTransfer for transfers, and disciplined rotation after each handover, you can give developers and support teams the access they need without leaving a trail of exposed credentials behind.
