Missing Tls in Feathersjs with Cockroachdb
Missing Tls in Feathersjs with Cockroachdb — how this specific combination creates or exposes the vulnerability
A Feathersjs application that connects to a Cockroachdb cluster without TLS exposes credentials and query data in transit. This specific combination is risky because Feathersjs typically manages service-side data access, and Cockroachdb connection strings often contain host, port, username, password, and database name. When TLS is missing, this information traverses the network unencrypted, making it susceptible to interception on compromised networks or through misrouted traffic.
During an unauthenticated scan, middleBrick tests the API surface for data exposure and encryption issues. If the API endpoint itself proxies or reveals backend connection metadata, or if the API provides administrative endpoints that return environment details, TLS gaps in the backend database connection may be observable through error messages or timing differences. Attackers can capture authentication tokens or query patterns, which may lead to lateral movement or privilege escalation within the database layer.
For compliance mappings, missing TLS aligns with OWASP API Security Top 10 controls related to transport security and can intersect with data exposure findings under standards such as PCI-DSS and SOC2. middleBrick’s checks include encryption assessments and data exposure detection, highlighting the absence of TLS as a finding with severity high and providing remediation guidance to enforce encrypted connections.
Cockroachdb-Specific Remediation in Feathersjs — concrete code fixes
To secure a Feathersjs service using Cockroachdb, enforce TLS for all database connections by configuring the client with the appropriate certificates. Below are concrete, working examples using the @cockroachdb/crdb driver, which supports TLS options for secure communication.
Example 1: Basic TLS connection with certificate verification
const feathers = require('@feathersjs/feathers');
const memory = require('feathers-memory');
const { Client } = require('@cockroachdb/crdb');
const app = feathers();
// Configure Cockroachdb client with TLS
const client = new Client({
host: 'your-cockroachdb-host',
port: 26257,
user: 'app_user',
password: 'strong_password',
database: 'app_db',
ssl: {
ca: '/path/to/ca.crt',
cert: '/path/to/client.crt',
key: '/path/to/client.key',
verifyHostname: true
}
});
// Connect and expose via Feathers service
client.connect()
.then(() => {
app.use('records', {
async find(params) {
const { rows } = await client.query('SELECT id, name, created_at FROM records', []);
return rows;
},
async get(id, params) {
const { rows } = await client.query('SELECT id, name, created_at FROM records WHERE id = $1', [id]);
return rows[0];
}
});
})
.catch(err => {
console.error('Connection or setup failed:', err);
});
app.setup();
Example 2: Insecure connection fallback prevention (rejecting non-TLS)
const insecureClient = new Client({
host: 'your-cockroachdb-host',
port: 26257,
user: 'app_user',
password: 'strong_password',
database: 'app_db',
ssl: {
rejectUnauthorized: true
}
});
// Ensure the driver enforces encryption by validating server certificate
insecureClient.connect()
.then(() => {
// Proceed only if TLS handshake succeeds
console.log('Secure Cockroachdb connection established');
})
.catch(err => {
// Handle certificate or connection errors explicitly
console.error('TLS verification failed:', err);
});
Operational guidance
- Store certificate files outside the application repository and reference them via environment paths or mounted secrets.
- Rotate certificates regularly and monitor connection logs for anomalies using your existing monitoring tools.
- Validate that your Feathersjs services do not expose database credentials or internal hostnames in error responses, as this can amplify the impact of missing TLS.
By implementing these patterns, the Feathersjs + Cockroachdb stack enforces encrypted transport, reducing the risk of credential theft and data exposure that middleBrick would flag under its encryption and data exposure checks.
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 |