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