Format String in Feathersjs with Cockroachdb

A format string vulnerability occurs when user-controlled input is passed directly into a formatting function without proper sanitization or parameterization. In a Feathersjs application using Cockroachdb, this typically arises when constructing SQL queries or building dynamic parameters for database operations using string concatenation or interpolation instead of prepared statements. Because Cockroachdb is PostgreSQL wire-compatible, it supports the same parameterization patterns as PostgreSQL, and misuse often maps to common weaknesses such as CWE-134 (External Control of Format String) or CWE-89 (SQL Injection).

Feathersjs services often expose query hooks where user-supplied data from REST or WebSocket transports can flow into database calls. If a developer writes raw queries using string concatenation, for example SELECT * FROM accounts WHERE id = '${userId}', and passes this to Cockroachdb via a driver that does not enforce parameter separation, the input may be interpreted as format specifiers. An attacker could supply payloads like %s, %x, or carefully crafted sequences to read stack contents or cause errors that leak internal state, which may assist further exploitation.

In a typical Feathersjs hook, logging or error formatting that includes unchecked user input can also become a vector if log messages or error responses are constructed with format functions such as util.format in Node.js and the attacker can influence the format string. For Cockroachdb, the risk is compounded when diagnostic or debug output is generated from query results that include attacker-influenced data, potentially exposing sensitive information through formatted output.

Consider a Featherjs service where a query is built dynamically:

// Risky: string concatenation with user input in a Feathers service hook
app.service('reports').hooks({
  before: {
    find: async context => {
      const { category } = context.params.query;
      // Unsafe: directly embedding user input into SQL string
      context.params.knex = context.app.get('knex').withSchema('public');
      const query = `SELECT * FROM reports WHERE category = '${category}'`;
      context.params.rawQuery = query;
      return context;
    }
  }
});

If category is controlled by an attacker and contains format specifiers, and if the query were built using format-style substitution rather than proper parameterization, it could lead to unintended interpretation. Even when using Knex, failing to use named or positional bindings correctly can reintroduce risk. Cockroachdb will still execute the query, but the exposure occurs at the application layer where format strings are handled before reaching the database.

To map to the middleBrick security checks, this scenario would be flagged under Input Validation, Property Authorization (if data access rules rely on query structure), and potentially Data Exposure if formatted output reveals sensitive information. The scanner evaluates whether the unauthenticated attack surface allows injection-like behaviors through format handling, even when the database itself uses parameterized protocols.

Remediation focuses on ensuring user input never influences the structure of SQL or the format string sent to Cockroachdb. Use parameterized queries or an ORM/query builder that enforces separation between code and data. In Feathersjs, configure your service hooks to rely on Knex bindings or the Feathers query parser, avoiding raw string assembly entirely.

Correct usage with Knex and Feathersjs:

// Safe: using Knex parameterized queries with user input as bindings
app.service('reports').hooks({
  before: {
    find: async context => {
      const { category } = context.params.query;
      // Use Knex where with bindings; no string interpolation
      context.params.knex = context.app.get('knex')
        .withSchema('public')
        .select('*')
        .from('reports')
        .where('category', category);
      return context;
    }
  }
});

If you need to execute raw SQL for complex operations, use parameterized placeholders supported by the Cockroachdb driver. With the pg-compatible driver, use $1, $2 style placeholders:

// Safe: raw query with explicit parameterization for Cockroachdb
const { db } = context.app.get('knex');
const safeQuery = 'SELECT * FROM reports WHERE category = $1';
const safeParams = [category];
const results = await db.raw(safeQuery, safeParams);
context.result = results.rows;

In services that accept multiple filter fields, prefer the Feathers query parser combined with Knex’s conditional building:

// Safe: leveraging Feathers query parser and Knex conditionals
app.service('reports').hooks({
  before: {
    find: async context => {
      const knex = context.app.get('knex').withSchema('public');
      const { $select, $where, category } = context.params.query;
      let query = knex.select().from('reports');
      if (category) {
        query = query.where('category', '=', category);
      }
      if ($select) {
        query = query.columns($select);
      }
      context.params.knex = query;
      return context;
    }
  }
});

For logging or error formatting, avoid passing raw user input into format strings. Instead, use structured logging or explicitly control the format:

// Safe: avoid format string injection in logs
const pino = require('pino');
const logger = pino();
app.service('reports').hooks({
  after: {
    find: context => {
      // Log with structured data, not interpolated format strings
      logger.info({ event: 'report_find', total: context.result.data.length });
      return context;
    }
  }
});

These practices align with the remediation guidance provided by middleBrick findings, which highlight Input Validation and Data Exposure checks. By adopting strict parameterization and avoiding dynamic format strings, you reduce the attack surface presented through the Feathersjs layer interacting with Cockroachdb.