Insecure Design in Express with Mongodb

Insecure design occurs when application architecture and data-flow decisions expose functionality that should be protected. In an Express application using MongoDB, several patterns commonly create or amplify vulnerabilities such as Insecure Direct Object References (IDOR), Overly Broad Assignment (Mass Assignment), and Injection via operator misuse.

Express does not enforce schema-level constraints or authorization boundaries by default. When route handlers directly map user-supplied parameters (e.g., :userId, :documentId) to MongoDB queries without authorization checks, attackers can manipulate these identifiers to access or modify other users' resources. For example, a route like /api/users/:userId/profile that constructs { _id: req.params.userId } without verifying that the authenticated actor owns that userId enables IDOR.

MongoDB operator misuse is another insecure design risk. If user input is deserialized and passed into update operations using operators like $set without strict filtering, attacker-controlled keys can modify unexpected fields. Consider an update that does User.updateOne({ _id: id }, req.body) where req.body is forwarded directly; an attacker could inject { role: 'admin' } to escalate privileges. This is a mass assignment / privilege escalation design flaw, not merely a validation gap.

Additionally, embedding sensitive data in URLs or client-managed state (e.g., JWTs stored in local storage without appropriate mitigations) reflects insecure design choices that increase data exposure risk. Without server-side session invalidation and strict transport controls, tokens can be leaked via referrer headers or XSS, compounding impact.

Insecure design also surfaces when error handling reveals stack traces or internal paths. Express apps that return verbose errors to clients can leak MongoDB collection names or query structures that aid reconnaissance. Proper status codes and sanitized messages are necessary design safeguards.

Finally, missing rate limiting and inadequate input validation at the API design layer can enable enumeration and brute-force attacks. Without design-time decisions to enforce per-user limits and strict schema validation (e.g., using a schema-aware layer before reaching MongoDB), attackers can probe IDs and operators to infer data relationships.

Remediation centers on enforcing authorization, constraining updates, and validating inputs before they reach MongoDB. Below are concrete Express patterns with valid MongoDB code examples using the native MongoDB driver for Node.js.

1. Enforce Ownership Checks (Prevent IDOR)

Always associate data with the authenticated subject and verify ownership on each request. Do not rely on client-supplied identifiers alone.

// GET /api/users/:userId/profile — secure version
app.get('/api/users/:userId/profile', async (req, res) => {
  const userId = req.params.userId;
  const authSubject = req.auth.userId; // from session/JWT

  if (authSubject !== userId) {
    return res.status(403).json({ error: 'Forbidden: cannot access other profiles' });
  }

  const profile = await db.collection('users').findOne({ _id: userId }, {
    projection: { name: 1, email: 1, settings: 1 }
  });
  res.json(profile);
});

2. Use Update Filtering to Prevent Mass Assignment

Never forward req.body directly to update operations. Define an allowlist of fields and use MongoDB update operators explicitly.

// PATCH /api/users/:userId — secure update with allowlist
const allowedFields = ['displayName', 'email', 'timezone'];

app.patch('/api/users/:userId', async (req, res) => {
  const userId = req.params.userId;
  const updates = {};

  allowedFields.forEach(field => {
    if (Object.prototype.hasOwnProperty.call(req.body, field)) {
      updates[field] = req.body[field];
    }
  });

  if (Object.keys(updates).length === 0) {
    return res.status(400).json({ error: 'No valid fields to update' });
  }

  const result = await db.collection('users').updateOne(
    { _id: userId },
    { $set: updates }
  );

  if (result.matchedCount === 0) {
    return res.status(404).json({ error: 'User not found' });
  }
  res.json({ ok: true });
});

3. Validate and Cast Input Before Query Construction

Ensure IDs are valid ObjectId instances and numeric fields are numbers to prevent query injection via malformed input.

// GET /api/items/:itemId — secure retrieval with validation
const { ObjectId } = require('mongodb');

app.get('/api/items/:itemId', async (req, res) => {
  if (!ObjectId.isValid(req.params.itemId)) {
    return res.status(400).json({ error: 'Invalid item ID format' });
  }

  const item = await db.collection('items').findOne({ _id: new ObjectId(req.params.itemId) });
  if (!item) {
    return res.status(404).json({ error: 'Item not found' });
  }
  res.json(item);
});

4. Avoid Operator Injection via User Keys

Strip keys that start with $ or contain dots when using user input in update pipelines, or map to a DTO.

// Sanitize update payload to prevent operator injection
function sanitizeUpdate(obj) {
  const clean = {};
  for (const key of Object.keys(obj)) {
    if (key.startsWith('$') || key.includes('.')) continue;
    clean[key] = obj[key];
  }
  return clean;
}

app.put('/api/docs/:docId', async (req, res) => {
  const docId = req.params.docId;
  const safeUpdate = sanitizeUpdate(req.body);
  const result = await db.collection('docs').updateOne(
    { _id: new ObjectId(docId) },
    { $set: safeUpdate }
  );
  res.json({ matched: result.matchedCount > 0 });
});

5. Apply Schema Validation and Error Sanitization

Use a validation layer (e.g., express-validator or a custom middleware) and avoid exposing internal paths in errors.

// Basic express-validator style checks
const { body, validationResult } = require('express-validator');

app.post('/api/users', [
  body('email').isEmail(),
  body('displayName').isString().trim().escape()
], async (req, res) => {
  const errors = validationResult(req);
  if (!errors.isEmpty()) {
    return res.status(400).json({ errors: errors.array() });
  }

  const user = {
    email: req.body.email,
    displayName: req.body.displayName,
    createdAt: new Date()
  };
  await db.collection('users').insertOne(user);
  res.status(201).json({ ok: true });
});