require-tls
Require TLS on Knex database connections, so queries and credentials are not sent in cleartext and the server is authenticated.
CWE: CWE-319 OWASP: A02:2021 – Cryptographic Failures
Detects Knex connection configuration that turns TLS off, or that keeps encryption but stops authenticating the server. This rule is part of eslint-plugin-knex-security.
💼 This rule is set to error in the strict config.
Quick Summary
| Aspect | Details |
|---|---|
| CWE Reference | CWE-319 (Cleartext Transmission of Sensitive Information) |
| Severity | High (CVSS 7.4) |
| Auto-Fix | ❌ No auto-fix available |
| Category | Security |
Why this matters
A database connection carries more sensitive data than almost anything else in an application: every query, every row that comes back, and the credentials used to open the session. With TLS off, all of it is readable by anything on the path — a shared VPC, a misconfigured load balancer, a compromised sidecar.
The second failure is subtler and more common. rejectUnauthorized: false
leaves encryption on, so a packet capture looks fine, but the client no longer
checks who it is talking to. It will happily complete a handshake with an
attacker who answered in the database's place, hand over the credentials, and
proxy every query. This is why the two cases are reported separately: the fix
for the first is "turn TLS on", and the fix for the second is "supply the CA",
never "switch the check off".
Knex nests its connection settings under connection, which accepts either an object or a URL string. Both forms are checked.
❌ Incorrect
import Knex from 'knex';
// ❌ plaintext — every query and the password cross the network in the clear
const db = Knex({ client: 'pg', connection: { host, user, password, ssl: false } });
// ❌ encrypted, but the server is never authenticated
const db2 = Knex({
client: 'pg',
connection: { host, ssl: { rejectUnauthorized: false } },
});
// ❌ the same decision, spelled in the URL
const db3 = Knex({ client: 'pg', connection: 'postgres://u:p@h/db?sslmode=disable' });✅ Correct
import Knex from 'knex';
// ✅ TLS on, server verified against a CA you supplied
const db = Knex({
client: 'pg',
connection: { host, user, password, ssl: { ca: fs.readFileSync(caPath) } },
});
// ✅ or state it in the URL
const db2 = Knex({ client: 'pg', connection: 'postgres://u:p@h/db?sslmode=verify-full' });What this rule deliberately does not report
- A value it cannot read.
ssl: useTlsorssl: process.env.DB_SSL === '1'is a decision made at runtime. Guessing there is how a security rule earns a false-positive reputation, so the rule stays silent — a deliberate false negative in exchange for findings that are always real. - A TLS key with no connection-shaped neighbour.
{ rejectUnauthorized: false }on its own is an https agent or a fetch option, not a database connection. That belongs toeslint-plugin-node-security, and reporting it here would double-report the same line from two plugins. - A file that never imports Knex. The driver import is the gate that keeps this rule inside its own plugin.
When Not To Use It
Local development against a database on the same host — a docker-compose Postgres reached over a loopback socket — has no network to protect. Disable the rule for those files rather than for the project, so the production configuration stays covered:
// eslint.config.js
export default [
{
// Filename-scoped on purpose. A directory glob such as `docker/**` would
// also switch the rule off for production connection code that happens to
// live there, which is the configuration this rule exists to protect.
files: ['**/*.local.ts'],
rules: { 'knex-security/require-tls': 'off' },
},
];Further Reading
- CWE-319: Cleartext Transmission of Sensitive Information
- CWE-295: Improper Certificate Validation — the weakness behind the
certificateValidationDisabledfinding - OWASP A02:2021 – Cryptographic Failures
- Knex connection options
Did this rule catch something? Star the repo to get new CWE coverage as we ship it — or follow the AI-code-security benchmarks behind these rules.