Skip to main content
interlace
Plugin: knex-securityRules

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

AspectDetails
CWE ReferenceCWE-319 (Cleartext Transmission of Sensitive Information)
SeverityHigh (CVSS 7.4)
Auto-Fix❌ No auto-fix available
CategorySecurity

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: useTls or ssl: 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 to eslint-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

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.