Broken Access Control in Mongodb

Broken Access Control in Mongodb APIs often stems from improper object ID handling and missing authorization checks. The most common pattern involves accepting client-provided object IDs without verifying ownership or permissions.

Consider a typical REST endpoint that retrieves a user's profile:

app.get('/api/users/:userId', async (req, res) => {
  const userId = req.params.userId;
  const user = await User.findById(userId);
  res.json(user);
});

This code has a critical flaw: it trusts the client-supplied userId parameter. An attacker can simply change the ID in the URL to access any user's data. If user 123's profile is at /api/users/123, the attacker can access user 456's data by requesting /api/users/456.

Mongodb's flexible schema makes this worse. Without strict type validation, an attacker might manipulate the ID format:

app.get('/api/orders/:orderId', async (req, res) => {
  const orderId = req.params.orderId;
  const order = await Order.findById(orderId);
  res.json(order);
});

If orderId is a string but should be an ObjectId, an attacker could potentially bypass validation by crafting special ID formats or using different query operators.

Another Mongodb-specific pattern involves aggregation pipelines that don't properly filter by user context:

app.get('/api/orders', async (req, res) => {
  const userId = req.user.id; // assuming authentication middleware
  const orders = await Order.aggregate([
    { $match: { status: 'pending' } },
    { $sort: { createdAt: -1 } }
  ]);
  res.json(orders);
});

Here, the aggregation pipeline processes all pending orders without filtering by the authenticated user, exposing data across user boundaries.

Property-level authorization failures are also common with Mongodb's document structure:

app.get('/api/users/:userId/profile', async (req, res) => {
  const userId = req.params.userId;
  const user = await User.findById(userId, { password: 0 });
  res.json(user);
});

While this excludes the password field, it still returns all other user data. If the user document contains sensitive fields like email, phone number, or address, these are exposed without proper authorization checks.

Mongodb's query operators can be abused when not properly sanitized:

app.get('/api/users', async (req, res) => {
  const query = req.query;
  const users = await User.find(query);
  res.json(users);
});

This endpoint allows arbitrary Mongodb queries through URL parameters, enabling attackers to use operators like $ne, $gt, or even $where for complex attacks.

Detecting Broken Access Control in Mongodb APIs requires both static analysis of the codebase and dynamic runtime testing. middleBrick's scanning approach tests the unauthenticated attack surface by attempting to access resources across user boundaries.

For Mongodb APIs, middleBrick tests for:

• Object ID manipulation across endpoints
• Missing user context in aggregation pipelines
• Property authorization failures in document retrieval
• Unsafe query parameter handling
• Role-based access control bypass attempts
• Cross-tenant data exposure in multi-tenant applications

Manual detection techniques include:

// Test for IDOR vulnerabilities
const axios = require('axios');

async function testBrokenAccessControl(baseUrl, userId, targetId) {
  try {
    // Try accessing another user's resource
    const response = await axios.get(`${baseUrl}/${targetId}`, {
      headers: { Authorization: `Bearer ${token}` }
    });
    
    if (response.status === 200) {
      console.log('Vulnerability found:', response.data);
    }
  } catch (error) {
    console.log('Access denied or error:', error.response?.status);
  }
}

Code review should focus on patterns where Mongodb queries accept external parameters without validation:

// Vulnerable pattern - no ownership check
const userIdParam = req.params.userId;
const user = await User.findById(userIdParam);

// Secure pattern - verify ownership
const userIdParam = req.params.userId;
const authenticatedUserId = req.user.id;
const user = await User.findOne({
  _id: userIdParam,
  owner: authenticatedUserId
});
if (!user) {
  return res.status(404).json({ error: 'Resource not found or unauthorized' });
}

Property-level authorization can be tested by examining which fields are returned and whether sensitive data is properly filtered:

const user = await User.findById(userId);
const { sensitiveData, ...safeUser } = user.toObject();
res.json(safeUser);

For aggregation pipelines, test whether user context is properly applied:

const orders = await Order.aggregate([
  { $match: { userId: authenticatedUserId, status: 'pending' } },
  { $sort: { createdAt: -1 } }
]);

middleBrick's LLM/AI Security checks are particularly relevant for Mongodb APIs that use AI features, as these endpoints often have additional access control requirements around system prompts and model parameters.

Remediating Broken Access Control in Mongodb requires implementing proper authorization checks at both the API and database query levels. The most effective approach combines middleware-based authorization with query-level filtering.

Middleware-based ownership verification:

const authorizeOwner = async (req, res, next) => {
  const { userId } = req.params;
  const authenticatedUserId = req.user.id;
  
  // Check if the resource belongs to the authenticated user
  const resource = await Resource.findById(userId);
  if (!resource || resource.owner.toString() !== authenticatedUserId) {
    return res.status(403).json({ error: 'Forbidden: Unauthorized access' });
  }
  
  next();
};

// Apply middleware to protected routes
app.get('/api/users/:userId', authorizeOwner, async (req, res) => {
  const user = await User.findById(req.params.userId);
  res.json(user);
});

Query-level filtering using Mongodb's query capabilities:

app.get('/api/orders', async (req, res) => {
  const userId = req.user.id;
  const { status } = req.query;
  
  const query = { userId };
  if (status) query.status = status;
  
  const orders = await Order.find(query)
    .sort({ createdAt: -1 })
    .limit(50);
    
  res.json(orders);
});

For aggregation pipelines, apply user context at the query level:

app.get('/api/reports', async (req, res) => {
  const userId = req.user.id;
  
  const pipeline = [
    { $match: { userId, createdAt: { $gte: new Date(Date.now() - 30*24*60*60*1000) } } },
    { $group: { _id: '$type', total: { $sum: '$amount' } } },
    { $sort: { total: -1 } }
  ];
  
  const report = await Report.aggregate(pipeline);
  res.json(report);
});

Property-level authorization using field projection:

const safeFields = {
  _id: 1,
  name: 1,
  email: 1,
  createdAt: 1
};

// Admin users get more fields
if (req.user.role === 'admin') {
  safeFields.role = 1;
  safeFields.lastLogin = 1;
}

const user = await User.findById(userId, safeFields);
res.json(user);

Using Mongodb's built-in role-based access control for database-level protection:

// Create application-specific roles
db.createRole({
  role: 'app_user',
  privileges: [
    {
      resource: { db: 'myapp', collection: 'users' },
      actions: ['find']
    }
  ],
  roles: []
});

// Grant role to application user
db.grantRolesToUser('app_user', ['app_user']);

For multi-tenant applications, implement tenant isolation:

const tenantMiddleware = async (req, res, next) => {
  const tenantId = req.user.tenantId;
  req.tenantFilter = { tenantId };
  next();
};

app.get('/api/data', tenantMiddleware, async (req, res) => {
  const data = await Data.find({
    ...req.tenantFilter,
    ...req.query
  });
  res.json(data);
});

middleBrick's continuous monitoring in the Pro plan can automatically scan your Mongodb APIs on a schedule, alerting you when new Broken Access Control vulnerabilities are detected.