Injection Flaws in Restify with Mongodb

Injection flaws occur when an attacker can supply untrusted input that is interpreted as part of a command or query. In a Restify service that uses Mongodb, this commonly arises when user-supplied data is placed directly into query objects, aggregation pipelines, or command-like operations without proper validation or sanitization. Because Restify encourages building JSON-based request handlers, developers may construct Mongodb queries by merging request parameters into filter objects, inadvertently enabling injection through operators such as $where, $eval, or through crafted dot-notation fields that traverse unintended document paths.

The unauthenticated scan behavior of middleBrick tests endpoints with no credentials, which can surface injection points that are reachable without authentication. For example, an endpoint like GET /users?role=admin that builds { role: req.query.role } and passes it to db.collection('users').find() may allow an attacker to inject additional conditions using JSON-encoded operators such as { "$ne": {} } or { "$or": [ { "email": { "$regex": ".*" } } ] }. Similarly, using string concatenation to form aggregation pipelines, such as Pipeline.fromUserInput(req.query.stage), can allow injection of malicious stages like { $project: { password: 1 } } or command-like stages that read or modify data in unexpected ways.

Because Mongodb supports dynamic expressions and flexible schema traversal, injection flaws can lead to data exfiltration, data modification, or exposure of sensitive fields. middleBrick’s checks for input validation, property authorization, and unsafe consumption are designed to detect these risks by comparing the runtime behavior against the OpenAPI/Swagger specification, including full $ref resolution, and by testing whether unauthenticated endpoints inadvertently permit manipulation of query structure. The scanner does not fix the code, but the findings include remediation guidance to ensure that user input is never interpreted as code or structure.

To prevent injection flaws when using Mongodb with Restify, keep all user input strictly outside of query and pipeline construction. Use typed, schema-validated objects and avoid dynamic operators that interpret strings as code. The following patterns illustrate secure approaches.

Secure query construction: Build filter objects explicitly and do not merge raw user input. Prefer whitelisting fields and using equality checks rather than operator-based inputs from clients.

const restify = require('restify');
const { MongoClient } = require('mongodb');

const server = restify.createServer();
const client = new MongoClient('mongodb://localhost:27017');

server.get('/users', async (req, res, next) => {
  const allowedRoles = ['user', 'admin', 'guest'];
  const role = allowedRoles.includes(req.query.role) ? req.query.role : 'guest';

  const collection = client.db('test').collection('users');
  const filter = { role: role };
  const user = await collection.findOne(filter);

  res.send(user || {});
  return next();
});

server.listen(8080, () => console.log('Listening on 8080'));

Safe aggregation with validated stages: If you must use aggregation, validate each stage against a strict schema and avoid passing raw user input into pipeline construction. Do not allow client data to define stage names or field projections directly.

const buildPipeline = (userInput) => {
  const allowedStages = ['matchActive', 'projectPublic'];
  if (!allowedStages.includes(userInput.action)) {
    throw new Error('Invalid pipeline action');
  }

  if (userInput.action === 'matchActive') {
    return [{ $match: { active: true } }];
  }

  if (userInput.action === 'projectPublic') {
    return [{ $project: { name: 1, email: 1, _id: 0 } }];
  }
};

server.post('/aggregate', async (req, res, next) => {
  const pipeline = buildPipeline(req.body);
  const cursor = client.db('test').collection('users').aggregate(pipeline);
  const results = await cursor.toArray();
  res.send(results);
  return next();
});

Avoiding dynamic operators and $where: Never use operators like $where, $eval, or construct queries from concatenated strings. Treat any field that could influence index selection or document traversal as sensitive, and validate against a known model.

// Unsafe — do not do this
// const cursor = db.collection('items').find({ $where: `this.value > ${userInput}` });

// Safe alternative: use numeric bounds with validation
const min = Number.isFinite(Number(req.query.min)) ? Number(req.query.min) : 0;
const cursor = db.collection('items').find({ value: { $gte: min } });

middleBrick’s checks for input validation and property authorization help surface cases where dynamic query building occurs, and its unauthenticated scan can reveal endpoints that expose these risks. The scanner provides prioritized findings with severity and remediation guidance, but it does not alter code or block requests. For teams using automated workflows, the CLI tool (middlebrick scan <url>) can be integrated into scripts, and the GitHub Action can add API security checks to your CI/CD pipeline to fail builds if risk scores exceed your chosen threshold.