Injection Flaws in Express with Mongodb

Injection flaws occur when an attacker can send data that changes the structure of a command or query. In Express applications using Mongodb, this often means untrusted input is used to build query objects or aggregation pipelines. Because Mongodb queries are expressed as JavaScript objects, unsanitized input can change operators, add new conditions, or inject unexpected stages, leading to unauthorized data access or modification.

For example, if an endpoint builds a find query by directly assigning user-supplied values into a filter object, an attacker can supply operator-like keys such as $where, $ne, or $or to alter the query semantics. Similarly, in aggregation pipelines supplied by the client, an attacker might inject a $merge or $out stage to write data elsewhere. Even when using Mongoose, deeply nested objects can include operators that bypass intended filters if input is not validated and sanitized.

Insecure deserialization or improper type coercion can further exacerbate the issue. If numeric IDs are expected but strings containing operators are accepted, Mongodb may interpret them as operators rather than values. This is especially risky when using the aggregation framework, where stages like $project or $group can be manipulated to expose additional fields or cause excessive computation. The unauthenticated attack surface of many Express endpoints means these flaws can be triggered without prior authentication, making injection a common and high-risk category in API security assessments.

Real-world attack patterns include attempts to bypass authentication by injecting {"$ne": null} into a username or password filter, or using $regex with overly broad patterns to trigger denial-of-service through resource exhaustion. In LLM security testing, outputs that include raw query structures can also lead to indirect injection if those outputs are later used to construct new queries without sanitization. Because these risks map to the OWASP API Top 10 Injection category, continuous scanning with tools that understand Mongodb-specific semantics is important for detecting insecure query construction.

Defensive query construction is the primary mitigation for injection flaws in Express with Mongodb. Always validate and sanitize incoming data, and avoid directly embedding user input into query objects or aggregation pipelines. Prefer parameterized patterns and explicit schema-based parsing.

Basic find query with user input

Instead of directly passing request query parameters into find, explicitly pick allowed fields and validate values:

// Unsafe: direct passthrough (vulnerable)
app.get('/users', (req, res) => {
  const filter = { username: req.query.username };
  db.collection('users').find(filter).toArray((err, docs) => {
    // handle response
  });
});

// Safer: allowlist known fields and avoid operator injection
app.get('/users', (req, res) => {
  const allowedFields = ['username', 'email'];
  const filter = {};
  if (req.query.username && allowedFields.includes('username')) {
    filter.username = req.query.username;
  }
  db.collection('users').find(filter).toArray((err, docs) => {
    // handle response
  });
});

Using $in with user input

When using operators, ensure values are validated and not raw user strings:

// Unsafe: user controls the entire $in array (potential injection)
app.get('/posts', (req, res) => {
  const tags = req.query.tags ? JSON.parse(req.query.tags) : [];
  db.collection('posts').find({ tags: { $in: tags } }).toArray((err, docs) => {
    // handle response
  });
});

// Safer: validate each element and use a fixed operator structure
app.get('/posts', (req, res) => {
  const raw = req.query.tags || '[]';
  let tags = [];
  try {
    tags = JSON.parse(raw);
  } catch (e) {
    return res.status(400).send('Invalid tags format');
  }
  if (!Array.isArray(tags) || tags.some(t => typeof t !== 'string')) {
    return res.status(400).send('Tags must be an array of strings');
  }
  const safeTags = tags.filter(t => t.length < 100); // length guard
  db.collection('posts').find({ tags: { $in: safeTags } }).toArray((err, docs) => {
    // handle response
  });
});

Aggregation pipeline safety

Avoid passing untrusted input into pipeline stages. If dynamic stages are required, validate and construct them explicitly:

// Unsafe: client-supplied pipeline (high risk)
app.post('/aggregate', (req, res) => {
  const pipeline = req.body.pipeline; // attacker-controlled
  db.collection('events').aggregate(pipeline).toArray((err, results) => {
    // handle response
  });
});

// Safer: compose pipeline server-side with safe parameters
app.post('/aggregate', (req, res) => {
  const matchStage = {};
  if (typeof req.body.status === 'string') {
    matchStage.status = req.body.status;
  }
  const safePipeline = [
    { $match: matchStage },
    { $group: { _id: '$category', total: { $sum: '$value' } } }
  ];
  db.collection('events').aggregate(safePipeline).toArray((err, results) => {
    // handle response
  });
});

Mongoose-specific notes

With Mongoose, prefer schema validation and avoid passing raw objects to model methods. Use lean queries where appropriate and sanitize nested paths:

// Unsafe: direct query from request
app.put('/items/:id', (req, res) => {
  Item.findByIdAndUpdate(req.params.id, req.body, { new: true }, (err, doc) => {
    // handle response
  });
});

// Safer: use schema paths and explicit update shape
app.put('/items/:id', (req, res) => {
  const update = {};
  if (typeof req.body.price === 'number') update.price = req.body.price;
  if (typeof req.body.name === 'string') update.name = req.body.name;
  Item.findByIdAndUpdate(req.params.id, { $set: update }, { new: true }, (err, doc) => {
    // handle response
  });
});

General practices

• Use strict schema validation and avoid passing req.body directly to query builders.
• Limit allowed operators on the server; treat any user-controlled operator-like keys as suspicious.
• Apply type checks and length limits on strings and arrays before using them in queries.
• Monitor for unexpected fields in aggregation pipelines that could indicate tampering.

Because findings map to compliance frameworks such as OWASP API Top 10 and SOC2, integrating continuous scanning that understands Mongodb semantics helps detect insecure patterns before they reach production. The middleBrick CLI can be run from the terminal to surface these issues: middlebrick scan <url>. For automated enforcement in development workflows, the GitHub Action can add API security checks to your CI/CD pipeline, and the MCP Server enables scanning APIs directly from your AI coding assistant.