HIGH missing tlsexpresscockroachdb

Missing Tls in Express with Cockroachdb

Missing Tls in Express with Cockroachdb — how this specific combination creates or exposes the vulnerability

When an Express application connects to a CockroachDB cluster without TLS, credentials and query data traverse the network unencrypted. This exposes authentication material and potentially sensitive application data to interception. A risk finding is generated when the scanner detects that the connection string or driver configuration does not enforce encrypted transport, and the target environment does not require TLS for database connections.

In practice, developers may configure the pg driver (used by CockroachDB) with a connection URL like postgresql://user:password@host:26257/dbname, omitting ?sslmode=require. Without this parameter, the driver may initiate a plaintext connection. If the cluster terminates TLS at the load balancer or accepts plaintext on the database port, the traffic between Express and CockroachDB is visible to anyone on the network path. This violates confidentiality protections expected by frameworks such as OWASP API Top 10 (A02:2023 — Cryptographic Failures) and standards like PCI-DSS and SOC2.

Additionally, missing server certificate validation can expose the application to man-in-the-middle attacks, even when TLS is enabled on the server side. For example, using { ssl: false } or omitting the ssl option entirely means the driver does not verify the server certificate. An attacker who can route traffic between the API host and the CockroachDB endpoint could present a self-signed certificate and decrypt or alter queries. The scanner checks whether the connection configuration enforces encryption and whether certificate validation is enabled, surfacing findings that align with Data Exposure and Encryption checks in middleBrick’s 12 parallel security tests.

When combined with unauthenticated or weakly authenticated endpoints in Express, missing TLS becomes a critical linkage point: an attacker who compromises API surface via IDOR or injection may pivot to the database using captured credentials. middleBrick’s scans include checks for unauthenticated endpoints and then evaluate whether database communications are protected, producing a prioritized finding with severity and remediation guidance tailored to the Express + CockroachDB stack.

Cockroachdb-Specific Remediation in Express — concrete code fixes

To secure the Express-to-CockroachDB path, enforce TLS and validate server certificates in the driver configuration. Below are concrete examples using the node-postgres driver (pg) commonly used with CockroachDB.

const { Pool } = require('pg');

// Secure connection string with sslmode=require
const connectionString = 'postgresql://user:password@host:26257/dbname?sslmode=require';

// Alternatively, configure ssl options explicitly for stricter validation
const pool = new Pool({
  connectionString: 'postgresql://user:password@host:26257/dbname',
  ssl: {
    rejectUnauthorized: true, // verify server certificate
    // Provide CA or cert/key if using client certificates or custom CAs
    ca: fs.readFileSync('/path/to/ca.pem').toString(),
  },
});

pool.query('SELECT $1::text as message', ['Hello, secure CockroachDB'], (err, res) => {
  if (err) {
    console.error('Query error:', err);
    return;
  }
  console.log(res.rows);
});

If you use an ORM or higher-level wrapper, ensure it passes the ssl configuration through to the underlying driver. For example, with an Express route that uses a database helper module:

// db.js
const { Pool } = require('pg');
const fs = require('fs');

const pool = new Pool({
  host: process.env.DB_HOST,
  port: Number(process.env.DB_PORT) || 26257,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME,
  ssl: process.env.NODE_ENV === 'production'
    ? {
        rejectUnauthorized: true,
        ca: fs.readFileSync(process.env.DB_CA_PATH).toString(),
      }
    : false, // only for local dev with self-signed certs; avoid in production
});

module.exports = pool;

// app.js
const express = require('express');
const pool = require('./db');
const app = express();

app.get('/items/:id', async (req, res) => {
  try {
    const result = await pool.query('SELECT id, name FROM items WHERE id = $1', [req.params.id]);
    res.json(result.rows[0]);
  } catch (err) {
    res.status(500).json({ error: 'Database error' });
  }
});

app.listen(3000, () => console.log('API running'));

For CockroachDB Serverless or secure clusters behind load balancers, verify that the balancer preserves client certificate information if mutual TLS is required. middleBrick’s scans flag missing sslmode=require or missing rejectUnauthorized: true as high-severity findings, with remediation guidance to update connection strings and certificate stores. The scanner also correlates these findings with the presence of unauthenticated endpoints, highlighting how weak transport security compounds other attack surfaces.

Finally, rotate credentials and update CA bundles regularly. In the Pro plan, continuous monitoring can alert you when a new scan detects that a connection string has reverted to a non-TLS configuration, enabling you to maintain encrypted pathways between Express and CockroachDB across deployments.

Related CWEs: encryption

CWE IDNameSeverity
CWE-319Cleartext Transmission of Sensitive Information HIGH
CWE-295Improper Certificate Validation HIGH
CWE-326Inadequate Encryption Strength HIGH
CWE-327Use of a Broken or Risky Cryptographic Algorithm HIGH
CWE-328Use of Weak Hash HIGH
CWE-330Use of Insufficiently Random Values HIGH
CWE-338Use of Cryptographically Weak PRNG MEDIUM
CWE-693Protection Mechanism Failure MEDIUM
CWE-757Selection of Less-Secure Algorithm During Negotiation HIGH
CWE-261Weak Encoding for Password HIGH

Frequently Asked Questions

Does middleBrick attempt to connect to my CockroachDB cluster during a scan?
middleBrick performs black-box testing against the submitted API endpoint only. It does not initiate connections to your CockroachDB cluster. Findings about missing TLS are based on configuration analysis of the API and observed runtime behavior, not direct database probing.
Can the scanner detect missing TLS when I use an OpenAPI spec to describe my API?
Yes. When you provide an OpenAPI/Swagger spec, middleBrick resolves $ref references and cross-references the declared server configurations and security schemes. If the spec describes a database connection or hints at backend transport requirements without enforcing TLS, the scan can surface related security findings alongside runtime checks.