Missing Tls in Adonisjs with Cockroachdb

When AdonisJS applications connect to CockroachDB without Transport Layer Security (TLS), credentials, session tokens, and query data traverse the network in plaintext. This exposes the application to network-level interception and credential theft, a scenario commonly seen in unsecured database deployments.

AdonisJS typically communicates with databases using a configuration object that specifies connection details. If the ssl parameter is omitted or set to false when connecting to CockroachDB, the underlying PostgreSQL driver establishes a non-encrypted TCP connection. CockroachDB supports TLS but does not enforce it unless configured to require it. This mismatch means an attacker on the same network segment, or an adversary who has compromised a network hop, can perform packet sniffing to recover sensitive information.

The risk is compounded by the fact that AdonisJS applications often run in diverse environments — development, staging, and production — where networking boundaries may be less strict. In such setups, a missing TLS setting in the AdonisJS config can lead to unauthenticated exposure of database traffic, aligning with the Data Exposure checks in middleBrick's 12 security scans. middleBrick can detect this misconfiguration during an unauthenticated scan, flagging the absence of encryption as a high-severity finding.

Real-world attack patterns include session hijacking and credential replay. For instance, if an application sends a username and password in plaintext to CockroachDB, an attacker can capture these and immediately authenticate to the database. This does not require a sophisticated exploit; it is a direct consequence of omitting TLS, a control that is well-understood but sometimes neglected in rapidly developed applications.

Compliance frameworks such as PCI-DSS and GDPR implicitly require encryption of data in transit when handling personal or payment data. A missing TLS configuration can therefore lead to non-compliance findings during audits. Using tools like middleBrick's OpenAPI and runtime analysis, teams can identify such gaps before they are exploited, receiving prioritized remediation guidance mapped to recognized standards.

To secure the AdonisJS and CockroachDB connection, you must enforce TLS in the database configuration. This involves setting the ssl option to an appropriate mode and ensuring the necessary certificates are available to the application.

Below is a secure configuration example for AdonisJS that enforces TLS when connecting to CockroachDB. This configuration sets ssl: 'require' to mandate encryption without full certificate verification, which is suitable for many environments. For stricter assurance, you can provide a CA certificate using ssl: { rejectUnauthorized: true, ca: fs.readFileSync('path/to/ca.pem') }.

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

const config: DatabaseConfig = {
  connection: 'cockroachdb',
  connections: {
    cockroachdb: {
      client: 'postgres',
      host: 'your-cockroachdb-host.cockroachdb.com',
      port: 26257,
      user: 'your-username',
      password: 'your-password',
      database: 'your-database',
      // Enforce TLS encryption for data in transit
      ssl: 'require',
      // For stricter security, use the following with a CA certificate:
      // ssl: {
      //   rejectUnauthorized: true,
      //   ca: fs.readFileSync('./cockroach-ca.pem').toString(),
      // },
    },
  },
}

export default config

In this configuration, the postgres client (which underlies AdonisJS's CockroachDB support) uses the ssl flag to initiate a secure connection. When set to 'require', the driver will attempt to upgrade the connection to TLS. If the server does not support TLS, the connection fails, preventing accidental plaintext communication.

For production deployments, it is recommended to use certificate validation. The example includes a commented block that shows how to provide a CA certificate. This ensures that the client verifies the server's identity, mitigating the risk of man-in-the-middle attacks even if the DNS or network is compromised.

After applying this configuration, you can verify the encryption by using middleBrick's CLI to scan the endpoint. The scan will report on encryption status as part of its Data Exposure checks, helping you confirm that TLS is active. Continuous monitoring plans in the Pro tier can alert you if a future change disables TLS, supporting ongoing compliance requirements.