HIGH nosql injectionfeathersjscockroachdb

Nosql Injection in Feathersjs with Cockroachdb

Nosql Injection in Feathersjs with Cockroachdb — how this specific combination creates or exposes the vulnerability

FeathersJS is a framework for building JavaScript APIs with a service-oriented architecture. When paired with CockroachDB, a distributed SQL database compatible with Postgres, developers typically use an ORM or query builder to interact with the database. Nosql Injection occurs when user-controlled input is directly interpolated into database queries without proper validation or parameterization, allowing an attacker to alter query logic.

In FeathersJS, services often define a find method that accepts a query object. If the service passes this object directly to the database driver without sanitization, an attacker can inject operators that change query behavior. For example, a query intended to filter by email can be manipulated to include additional conditions or bypass authentication checks.

With CockroachDB, which uses a Postgres-wire compatible protocol, the risk manifests when FeathersJS services use raw query strings or dynamic object construction. Consider a service that builds a WHERE clause by merging user input into an object. An attacker could supply a payload such as {"$or": [{"email": "normal@example.com"}, {"email": "attacker@example.com"}]} as a query parameter. If the service does not validate or restrict operators, this input can be interpreted as logical operators, returning unintended rows.

Real-world patterns include using the feathers-sequelize adapter or similar ORMs that may expose operator symbols (e.g., $eq, $like) without sanitization. An example vulnerable service might look like this:

app.use('/users', createService({
  Model: CockroachDBModel,
  paginate: { default: 10, max: 50 },
  async find(params) {
    const { email } = params.query;
    // Vulnerable: directly using user input in query
    return await this.Model.findAll({
      where: { email }
    });
  }
}));

An attacker could manipulate the email parameter to inject logical operators if the ORM or database driver does not strictly parse types. Although CockroachDB enforces strict typing, the ORM layer may still allow operator injection when constructing dynamic objects. This can lead to authentication bypass, data exfiltration, or enumeration.

Additionally, nested query objects can amplify risk. For instance, if a service allows deep query parameters like {"profile.age": {"$gt": 18}}, an attacker might supply {"profile.age": {"$gt": 0, "$lt": 1000}} to refine data extraction. The FeathersJS service must explicitly define allowed fields and operators to prevent such manipulation.

Because middleBrick scans test unauthenticated attack surfaces, it can detect these injection patterns by analyzing the API schema and runtime behavior. Findings often map to OWASP API Top 10 categories such as Broken Object Level Authorization and Injection. For remediation, developers should adopt strict input validation, use parameterized queries, and limit allowed operators.

Cockroachdb-Specific Remediation in Feathersjs — concrete code fixes

To prevent Nosql Injection in FeathersJS with CockroachDB, developers must enforce strict input validation and avoid dynamic query construction. The following practices and code examples demonstrate secure implementations.

1. Use parameterized queries or an ORM with built-in sanitization

Instead of directly embedding user input, use placeholders or query builders that separate data from commands. With CockroachDB, you can use knex or sequelize with parameterized inputs.

// Secure example using knex with parameterized queries
const knex = require('knex')({ client: 'pg' });
app.use('/users', createService({
  Model: knex('users'),
  async find(params) {
    const { email } = params.query;
    // Parameterized filter ensures input is treated as data
    const results = await this.Model.where('email', email).select();
    return results;
  }
}));

2. Validate and sanitize incoming query objects

Explicitly define allowed fields and reject unexpected operators. Use a validation library or custom middleware to strip dangerous keys.

// Validation middleware for FeathersJS
const sanitizeQuery = (allowedFields) => (context) => {
  const query = context.params.query || {};
  const sanitized = {};
  for (const key of Object.keys(query)) {
    if (allowedFields.includes(key) && typeof query[key] === 'string') {
      sanitized[key] = query[key];
    }
  }
  context.params.query = sanitized;
  return context;
};

app.use('/users', createService({
  Model: CockroachDBModel,
  async find(params) {
    // After sanitization, safe to use
    const { email } = params.query;
    return await this.Model.findAll({ where: { email } });
  }
}));
app.hooks.set({
  before: {
    all: [sanitizeQuery(['email', 'username'])]
  }
});

3. Restrict operators and deep nesting

Explicitly block MongoDB-style operators (e.g., $or, $gt) even if using an ORM that supports them. CockroachDB does not natively use these operators, but an ORM layer might interpret them incorrectly.

// Reject operators in query
const operatorPattern = /^\$/;
const sanitizeStrict = (context) => {
  const traverse = (obj) => {
    for (const key in obj) {
      if (operatorPattern.test(key)) {
        throw new Error('Operator not allowed');
      }
      if (typeof obj[key] === 'object' && obj[key] !== null) {
        traverse(obj[key]);
      }
    }
  };
  traverse(context.params.query || {});
  return context;
};

app.use('/users', createService({
  Model: CockroachDBModel,
  async find(params) {
    const { email } = params.query;
    return await this.Model.findAll({ where: { email } });
  }
}));
app.hooks.set({
  before: {
    all: [sanitizeStrict]
  }
});

4. Leverage middleBrick for continuous verification

Using the middleBrick CLI, developers can regularly scan their endpoints to ensure remediation is effective. The command middlebrick scan <url> runs the 12 security checks, including Injection and BOLA/IDOR tests, against the unauthenticated API surface.

For teams integrating security into development workflows, the GitHub Action can fail builds if the risk score drops below a defined threshold, while the MCP Server allows scanning directly from AI coding assistants in the IDE.

These steps reduce the attack surface and align with compliance frameworks such as OWASP API Top 10 and SOC2, ensuring that CockroachDB-backed FeathersJS services remain resilient against injection attacks.

Frequently Asked Questions

How can I test if my FeathersJS service is vulnerable to Nosql Injection?
You can test by sending query parameters with operators such as {"$or": [...]} or deeply nested objects to your service endpoints. If the API returns unexpected data or bypasses authentication, it may be vulnerable. Use middleBrick to scan your API, which checks for injection patterns without requiring credentials.
Does using CockroachDB eliminate Nosql Injection risks in FeathersJS?
No. CockroachDB uses SQL semantics, but insecure service code in FeathersJS can still allow operator injection through ORM or query builder misuse. Proper input validation and parameterized queries are required regardless of the database.