Skip to main content

Database URI with Credentials

A Database URI with embedded credentials is a connection string used to authenticate and connect to a database service. This URI typically includes the username, password, host, and database name, allowing applications to establish a connection seamlessly. However, if exposed, these credentials can grant unauthorized access to the database, posing a significant security risk. Unauthorized access can lead to data breaches, data manipulation, and other malicious activities, making it crucial to protect these URIs from exposure.

How Does It Look​

Database URIs with credentials can appear in various contexts, such as:

  • Environment variables:

    export DATABASE_URI="mongodb://user:password@host:27017/dbname"

  • Configuration files (JSON, YAML, .env):

    {
      "database_uri": "postgresql://user:password@host:5432/dbname"
    }
    database_uri: "mysql://user:password@host:3306/dbname"

  • Code snippets:

    connection = connect("mongodb://user:password@host:27017/dbname")

  • Connection strings:

    mongodb://user:password@host:27017/dbname

Severity​

  • 🔴 Critical

The severity of exposing a Database URI with credentials is critical because it provides direct access to the database. This access can lead to unauthorized data retrieval, modification, or deletion. The blast radius is extensive, potentially affecting all data within the database and any dependent applications.

What Can an Attacker Do?​

With immediate access to the database, an attacker can perform a variety of malicious actions:

  • Read sensitive data (if the credential has read permissions), potentially leading to data breaches.
  • Delete or modify data (if the credential has write permissions), which can disrupt operations and lead to data loss.
  • Access billing information (if the account has billing scope enabled), potentially leading to financial exploitation.
  • Spin up resources for cryptomining (if compute permissions are granted), causing unexpected costs.

Additionally, an attacker could use the database access to escalate privileges or move laterally within the network, targeting other systems and services connected to the database.

Real-World Impact​

The exposure of a Database URI with credentials poses significant business risks, including:

  • Data Exposure: Sensitive customer or business data could be accessed (if the credential has read access to sensitive data).
  • Financial Loss: Unauthorized resource usage or data manipulation could incur costs (if billing/resource creation is permitted).
  • Operational Disruption: Critical applications relying on the database could fail (if the attacker has delete/modify permissions).
  • Reputational Damage: Loss of customer trust and brand integrity due to data breaches.

In worst-case scenarios, the cascading effects of such exposure could lead to prolonged downtime, regulatory scrutiny, and substantial financial penalties.

Prerequisites for Exploitation​

To exploit a Database URI with credentials, an attacker needs:

  • Network access to the database host.
  • Knowledge of the database endpoint and any required account IDs.
  • Bypassing any rate limits or IP restrictions that may be in place.

How to Verify If It's Active​

To verify if a Database URI with credentials is active, use the following command:

psql "postgresql://[USER]:[PASSWORD]@[HOST]:5432/[DBNAME]"

Valid credential response: Successful connection message or database prompt.

Invalid/expired credential response: Authentication failed error or connection refused message.

Detection Patterns​

Common Variable Names:

  • DATABASE_URI
  • DB_CONNECTION_STRING
  • MONGO_URI
  • POSTGRES_URI
  • MYSQL_URI
  • SQLALCHEMY_DATABASE_URI

File Locations:

  • .env
  • config.json
  • settings.yaml
  • database.yml
  • appsettings.json

Regex Pattern:

[a-z]+:\/\/[a-zA-Z0-9]+:[a-zA-Z0-9]+@[a-zA-Z0-9.-]+:[0-9]+\/[a-zA-Z0-9]+

Remediation Steps​

  1. Revoke immediately - Go to your database management console and change the password for the compromised user.
  2. Audit access logs - Review database access logs for unauthorized queries or data exports during the exposure window.
  3. Assess blast radius - Identify all systems, applications, and environments that used the exposed credential.
  4. Rotate credential - Create a new database user with least-privilege permissions and update the URI.
  5. Update dependent systems - Deploy the new credential to all applications and update CI/CD pipelines securely.
  6. Harden access controls - Enable IP allowlisting and require TLS connections for database access.
  7. Implement secrets management - Migrate credentials to a secrets manager (HashiCorp Vault, AWS Secrets Manager) to prevent hardcoding.
  8. Add detection controls - Set up pre-commit hooks and repository scanning to catch credential leaks before they reach production.

Credential exposures often go undetected for extended periods, increasing the window for exploitation. As a long-term strategy, plan to establish an internal process or engage an external vendor for continuous external exposure monitoring. This helps identify leaked secrets across public repositories, paste sites, dark web forums, and other external sources before attackers can leverage them. Proactive detection and rapid response are essential to minimizing the impact of credential leaks.

References​