Injection Flaws in Mongodb

Injection flaws in Mongodb applications occur when untrusted data is concatenated directly into database queries without proper sanitization. Unlike SQL injection, Mongodb injection exploits the query language's document-based structure and operator syntax.

The most common Mongodb injection pattern involves constructing queries with string concatenation:

const userId = req.query.id;
const query = `{
  "user_id": "${userId}",
  "status": "active"
}`;
collection.find(query).toArray();

An attacker can inject Mongodb operators by crafting malicious input:

// Malicious input: " || true || \""
// Results in: { "user_id": "" || true || "", "status": "active" }
// Returns ALL documents regardless of user_id

Another dangerous pattern uses JavaScript evaluation in Mongodb's $where operator:

const userInput = req.query.search;
const query = { $where: `this.name.includes('${userInput}')` };

This allows arbitrary JavaScript execution if userInput contains malicious code like '; return this.admin === true; //.

Object injection is particularly subtle in Mongodb:

const filter = { status: 'active' };
if (req.query.id) filter._id = req.query.id;
collection.find(filter);

If an attacker sends ?id[$ne]=0, the query becomes { _id: { $ne: 0 }, status: 'active' }, bypassing ID restrictions.

Parameter pollution can also trigger injection:

// Request: GET /api/items?id=123&id[$gt]=0
// Results in: { _id: [ '123', { $gt: 0 } ] }

This array-based injection can cause unexpected query behavior or errors that leak information.

Detecting Mongodb injection requires analyzing both the application code and the API surface. Static analysis tools look for dangerous patterns like string concatenation in query construction, use of $where operator with dynamic input, and improper handling of nested objects.

Dynamic scanning with middleBrick specifically tests for Mongodb injection by sending payloads designed to trigger operator injection:

// Test for operator injection
?id[$ne]=0 → checks if $ne operator bypasses filters
?id[$exists]=true → checks if $exists operator works
?id[$gt]=999999 → checks if $gt operator returns unexpected results

middleBrick's scanner constructs these payloads automatically and analyzes the API's response patterns to determine if injection succeeded. The tool examines whether responses contain more data than expected, error messages revealing database structure, or status codes indicating different execution paths.

API security monitoring should also check for:

• Excessive data exposure in error responses (stack traces containing Mongodb driver details)
• Unexpected query performance (injection often causes full collection scans)
• Inconsistent response formats when special characters are included in parameters

Runtime detection can use Mongodb's built-in auditing to log query patterns and identify suspicious operations like frequent $where usage or unusual operator combinations.

The most effective remediation for Mongodb injection is using parameterized queries with proper typing. Instead of constructing query strings, use Mongodb's native query objects:

// Vulnerable
const userId = req.query.id;
const query = { user_id: userId };

// Secure - type validation
const userId = req.query.id;
if (!ObjectId.isValid(userId)) throw new Error('Invalid ID');
const query = { user_id: new ObjectId(userId) };

For text search, avoid $where operator entirely:

// Vulnerable - JavaScript injection
const query = { $where: `this.name.includes('${search}')` };

// Secure - regex with proper escaping
const query = { name: { $regex: search, $options: 'i' } };

Input validation should be strict and type-specific:

function validateMongoId(id) {
  if (typeof id !== 'string') return false;
  if (!/^[a-f0-9]{24}$/.test(id)) return false;
  return true;
}

Always use projection to limit returned fields:

// Instead of returning entire document
collection.find(query).toArray();

// Specify exact fields needed
collection.find(query, { projection: { password: 0, sensitiveData: 0 } }).toArray();

For complex queries, use aggregation pipelines which provide better separation between data and query logic:

const pipeline = [
  { $match: { status: 'active' } },
  { $lookup: { from: 'users', localField: 'user_id', foreignField: '_id', as: 'user' } },
  { $project: { name: 1, user: { name: 1 } } }

Implement query whitelisting for API endpoints that accept filter parameters:

const allowedFilters = ['status', 'category', 'created_after'];
const query = {};
for (const [key, value] of Object.entries(req.query)) {
  if (!allowedFilters.includes(key)) continue;
  // Apply specific validation per field
  if (key === 'created_after') query.created = { $gte: new Date(value) };
  else query[key] = value;
}