Phishing Api Keys in Adonisjs with Cockroachdb

When an AdonisJS application connects to CockroachDB with hard‑coded or poorly managed API keys / connection credentials, the overall API surface can unintentionally expose secrets. The risk typically arises from insecure handling of database configuration and runtime values rather than a CockroachDB protocol weakness.

In AdonisJS, database configuration is centralized in config/database.ts. If this file (or its source‑control history) contains literal API keys, database passwords, or cloud‑provider tokens, those strings can be exposed to an attacker who gains access to the repository, build logs, or runtime environment. An attacker may then use the exposed keys to authenticate to CockroachDB, exfiltrate data, or tamper with the dataset. Because AdonisJS applications often run in containerized or serverless environments, environment variables are commonly injected at runtime; if those variables are logged, leaked in error messages, or weakly guarded by the hosting platform, the keys can be phished.

Another vector specific to this combination is insecure deserialization or unsafe consumption of user input that ultimately forms database connection parameters. For example, if an endpoint dynamically builds a CockroachDB connection string using unvalidated input (e.g., a tenant identifier), an attacker could inject malicious connection options that redirect queries or cause credentials to be disclosed in logs. SSRF-style mistakes can also lead to internal metadata services being queried for credentials when the runtime environment relies on instance metadata for authentication.

LLM/AI security checks are relevant because an endpoint that returns database configuration snippets or debug information might inadvertently leak system prompts or API keys in model outputs. middleBrick’s LLM/AI Security actively tests for system prompt leakage and scans LLM responses for API keys and PII, helping detect accidental exposure of CockroachDB connection details through AI-assisted interfaces.

To map findings to real-world issues, consider references to the OWASP API Top 10 (e.g., Broken Object Level Authorization and Security Misconfiguration), common misconfigurations in connection strings, and patterns seen in incidents where hard‑coded secrets led to unauthorized database access.

Secure the AdonisJS + CockroachDB stack by ensuring credentials are never stored in source code, are transmitted and stored securely, and are validated before use. Use environment variables injected by the host platform, encrypt secrets at rest, and avoid dynamic concatenation of connection strings from user input.

1. Use environment variables with strong validation

Store CockroachDB connection credentials as environment variables and reference them in config/database.ts. Validate and sanitize values before use.

// config/database.ts
import Env from '@ioc:Adonis/Core/Env'
import { DatabaseConfig } from '@ioc:Adonis/Lucid/Database'

const dbConfig: DatabaseConfig = {
  connection: 'cockroachdb',
  connections: {
    cockroachdb: {
      client: 'cockroachdb',
      connection: {
        host: Env.get('DB_HOST', 'localhost'),
        port: Env.get('DB_PORT', 26257),
        user: Env.get('DB_USER', 'root'),
        password: Env.get('DB_PASSWORD', ''),
        database: Env.get('DB_NAME', 'default_db'),
        // Use SSL in production; CockroachDB recommends secure connections
        ssl: Env.get('DB_SSL', 'true') === 'true'
          ? { rejectUnauthorized: false } // adjust CA in production
          : false
      },
      debug: false
    }
  }
}

export default dbConfig

Ensure the environment variables are managed via a secrets manager or platform‑provided secret store, never committed to version control. Add runtime validation to reject malformed hosts or ports.

2. Avoid dynamic credential building from user input

Do not construct connection strings or modify configuration based on request parameters. If multi‑tenant routing is required, keep the CockroachDB credentials static and isolate data via schema or row‑level security, not by dynamically reconfiguring connections.

// Bad: dynamically building connection options from request input
// Avoid this pattern
const tenantHost = ctx.request.input('host') // DO NOT DO THIS
const password = ctx.request.input('password') // DO NOT DO THIS

// Good: use static credentials and tenant-aware routing logic
// Keep credentials stable; apply tenant identification after authentication
const tenantId = ctx.params.id
// Route queries using tenantId with a static, validated connection

3. Protect logs and error messages

Ensure that database errors do not leak passwords or connection strings. Configure AdonisJS to mask sensitive fields in logs and avoid echoing raw configuration in responses.

// start/hooks.ts
import { ExceptionHandler } from '@ioc:Adonis/Core/ExceptionHandler'

export default class CustomExceptionHandler extends ExceptionHandler {
  public handle(error: any) {
    // Mask sensitive details in logs
    if (error.code === '28P01' || error.message?.includes('password')) {
      error.message = 'Authentication failed'
    }
    super.handle(error)
  }
}

4. Enforce least‑privilege and network controls

Create CockroachDB users with minimal required permissions and restrict network access to the application host only. Rotate credentials regularly using your secrets manager. For workloads requiring automated rotation, integrate with a provider that supports dynamic credentials where possible.

5. Use middleBrick to detect exposed configuration

Run middleBrick scans against your API endpoints to identify accidental exposure of configuration details, insecure deserialization risks, or endpoints that may leak system prompts containing CockroachDB connection information. The CLI and GitHub Action integrations can enforce a minimum security score before deployment, while the Web Dashboard tracks findings over time.