no-unsafe-query

Prevents SQL injection by detecting string concatenation or template literals with variables in client.query() calls.

🚨 Security rule | 💡 Provides LLM-optimized guidance | ⚠️ Set to error in recommended

Quick SummaryCopy Anchor Link

Value & investment caseCopy Anchor Link

Why this rule pays for itself. Framework: cicd-impact/philosophy.md.

Read also: philosophy.md §investor-frame · niche-presets.json · analyzer-evaluation-framework.md

Rule DetailsCopy Anchor Link

SQL injection is one of the most critical security vulnerabilities. This rule detects potentially unsafe SQL query construction in pg driver calls.

❌ IncorrectCopy Anchor Link

// Template literal with variable
const result = await client.query(`SELECT * FROM users WHERE id = ${userId}`);

// String concatenation
const query = "SELECT * FROM users WHERE name = '" + userName + "'";
await pool.query(query);

✅ CorrectCopy Anchor Link

// Parameterized query
const result = await client.query('SELECT * FROM users WHERE id = $1', [
  userId,
]);

// Named parameters (with pg-named or similar)
const result = await client.query({
  text: 'SELECT * FROM users WHERE id = $1',
  values: [userId],
});

Error Message FormatCopy Anchor Link

The rule provides LLM-optimized error messages (Compact 2-line format) with actionable security guidance:

🔒 CWE-89 OWASP:A05 CVSS:9.8 | SQL Injection detected | CRITICAL [SOC2,PCI-DSS,HIPAA,ISO27001]
   Fix: Review and apply the recommended fix | https://owasp.org/Top10/A05_2021/

Message ComponentsCopy Anchor Link

What the rule treats as safe inside an interpolationCopy Anchor Link

A value interpolated into SQL is accepted only when the file can prove it safe structurally — never because of what a variable is called:

• a constant: a literal, a const that folds to one, a member of a const object literal, or a TypeScript enum member with a literal initialiser;
• a bind-parameter index after a single $ — $${params.length}, $${i + 1}, $${params.push(v)} — the dynamic-filter builder idiom. The index must be provably a number: .length, .push(…), a counter, a Number() / parseInt / Math.* result, arithmetic, a : number parameter or an array callback's index argument. $${n} where n is an untyped parameter or request data is reported;
• a SET or column list filled only with fixed text — sets.push(`name = $${values.length}`) then ${sets.join(', ')} — or the element of a for…of over a fixed column array. Column names from Object.keys(req.body) / Object.entries(req.body) are not fixed text and are reported;
• a placeholder list: ids.map((_, i) => `$${i + 1}`).join(', '), inline or bound to a const first;
• a closed list of escapers and conversions: escapeIdentifier / escapeLiteral (pg), anything from pg-format, pg-promise's pgp.as.*, Number / parseInt / parseFloat, and Math.*.

Any other call is not an escaper: ${ids.join(',')}, ${email.trim()} and ${String(name)} are reported.

SinksCopy Anchor Link

Sinks are query / execute, pg-promise's none, one, oneOrNone, many, manyOrNone, any, result, multi, multiResult, and postgres.js sql.unsafe. The rule runs only in files with PostgreSQL SDK evidence (an import of pg, pg-promise, postgres, … or a postgres:// DSN), and a SQL-shaped string built from a raw value is required, so GraphQL client.query({ query }), analytics .query('event:…') and DOM queries stay quiet.

Route files that import a local db wrapperCopy Anchor Link

A file that reaches PostgreSQL only through import * as db from '../db' is linted when ../db resolves to a file on disk that itself imports pg, pg-pool, pg-promise or postgres (directly, or through a short chain of relative re-exports). That is real PostgreSQL evidence one hop away, which satisfies the SDK gate contract shared with the sibling SQL plugins. A relative import with nothing on disk behind it, or a ../db that imports mongoose or redis, keeps the rule silent.

Query builders imported from a relative module are read in that module: a builder that returns an interpolated template, or assembles q over several statements and returns it, is judged exactly as one written in the same file.

Known False NegativesCopy Anchor Link

The following patterns are not detected due to static analysis limitations:

Tagged Template Literals (sql...)Copy Anchor Link

Why: Tagged templates like sql from libraries are function calls, not template literals.

// ❌ NOT DETECTED - appears safe but may not be
import { sql } from 'some-library';
await client.query(sql`SELECT * FROM users WHERE id = ${userId}`);
// If 'sql' doesn't properly escape, this is vulnerable!

Mitigation: Use a library verified to properly escape tagged templates.

Dynamic Query VariablesCopy Anchor Link

Why: A builder from an npm package, or one reached through a path alias (@/queries), cannot be read. Builders in the same file and in RELATIVE modules are followed.

// ❌ NOT DETECTED
import { buildQuery } from '@/queries';
const unsafeQuery = buildQuery(userInput); // May concatenate strings internally
await client.query(unsafeQuery);

Mitigation: Always use parameterized queries ($1, $2) directly in literals.

Nested Function CallsCopy Anchor Link

Why: Queries passed through helper functions aren't traced.

// ❌ NOT DETECTED
function executeQuery(query: string) {
  return client.query(query);
}
executeQuery(`SELECT * FROM users WHERE id = ${userId}`);

Mitigation: Apply the rule to helper functions that execute queries.

Format Functions with User InputCopy Anchor Link

Why: The rule doesn't track data flow through pg-format or similar.

// ❌ NOT DETECTED - but format() should handle escaping
import format from 'pg-format';
await client.query(format('SELECT * FROM %I.users', userSchema));
// Safe if format() escapes, but rule can't verify

Mitigation: Use parameterized queries for values; use verified formatters only for identifiers.

When Not To Use ItCopy Anchor Link

• When using a query builder (Drizzle, Kysely) that handles parameterization
• In migration files with static SQL

Related RulesCopy Anchor Link

• check-query-params - Validates parameter count
• no-batch-insert-loop - Prevents N+1 queries

If this rule caught a real vulnerability in your codebase, ⭐ star the repo — it keeps the detection logic maintained.