Man In The Middle in Express with Cockroachdb

A Man In The Middle (MitM) attack against an Express service using CockroachDB occurs when an attacker intercepts or alters traffic between the application and the database. This typically happens when connections are not properly encrypted or when certificate validation is skipped. CockroachDB supports TLS for client connections, but if the Express app connects without enforcing secure settings, credentials, session tokens, or query parameters can be exposed in transit.

In a typical Express + CockroachDB setup, the application uses a connection string or options object to communicate with the cluster. If ssl is not enforced or rejectUnauthorized is not set appropriately, an attacker on the network can position themselves between the process and the database nodes. This enables credential harvesting, session hijacking, or even query manipulation. For example, a connection string like postgresql://user:password@host:26257/db?sslmode=disable explicitly disables encryption, making interception trivial.

The risk is compounded when combined with other weaknesses such as improper authentication or BOLA/IDOR, because intercepted session identifiers or API keys can be reused. middleBrick scans for unauthenticated endpoints and insecure configurations, flagging cases where TLS is missing or misconfigured in the runtime behavior of the API. This is especially important for CockroachDB deployments that span multiple regions or use load balancers, where traffic might traverse public networks.

Without active validation of server certificates, an attacker can perform a downgrade attack or present a forged certificate, and the Express app may accept it. middleBrick’s Encryption and Data Exposure checks help detect these misconfigurations by analyzing the unauthenticated attack surface and identifying when connections do not enforce encryption or leak sensitive data in responses.

To secure communication between Express and CockroachDB, enforce TLS with strict certificate validation. Never use sslmode=disable in production. Instead, require full verification and provide the appropriate CA certificate. Below are concrete, working examples demonstrating secure configuration.

Secure connection using the pg driver

The pg library is commonly used with CockroachDB in Node.js. Use the following options to enforce TLS and validate the server identity.

const { Client } = require('pg');
const fs = require('fs');

const client = new Client({
  connectionString: 'postgresql://myuser:mypassword@my-cockroachdb-host:26257/mydb?sslmode=verify-full',
  ssl: {
    ca: fs.readFileSync('/path/to/ca.crt').toString(),
    rejectUnauthorized: true
  }
});

client.connect()
  .then(() => console.log('Connected securely to CockroachDB'))
  .catch(err => {
    console.error('Connection error:', err);
  });

Key settings explained:

• sslmode=verify-full ensures the server certificate is verified and matches the hostname.
• ca provides the Certificate Authority certificate used to sign the CockroachDB server certificates.
• rejectUnauthorized: true ensures the TLS handshake fails if the certificate cannot be verified.

Environment-based configuration for different stages

Use environment variables to manage configuration across development, staging, and production. This avoids hardcoding values and supports the Pro plan’s continuous monitoring capabilities by making configuration auditable.

const isProduction = process.env.NODE_ENV === 'production';

const client = new Client({
  connectionString: process.env.DATABASE_URL,
  ssl: isProduction
    ? {
        ca: fs.readFileSync('/path/to/ca.crt').toString(),
        rejectUnauthorized: true
      }
    : { rejectUnauthorized: false } // only for local testing
});

In CI/CD pipelines, the GitHub Action can enforce that these secure settings are present in configuration files before deployment. This prevents accidental use of insecure settings in production. The MCP Server allows you to run these checks directly from development environments, integrating security into the coding workflow.

Additional Express-level protections

Ensure that sensitive data is not logged or exposed in error messages. Use secure headers and enforce HTTPS at the load balancer or reverse proxy level. Combine these practices with regular scans using middleBrick to validate that encryption and data exposure checks pass consistently.