Security Misconfiguration in Express with Mongodb

Security misconfiguration in an Express application that uses MongoDB often arises from a mismatch between permissive HTTP settings and overly broad database access rules. When authentication or authorization checks are missing or inconsistent, an attacker can manipulate endpoints to interact with MongoDB in unintended ways.

Common misconfigurations include:

• Permissive CORS settings that allow cross-origin requests from untrusted origins, enabling unauthorized web applications to invoke API routes that reach MongoDB.
• Missing or weak validation on route parameters, which permits injection-like behavior through operators such as $where, $eval, or regex patterns that affect query shape.
• Default or shared MongoDB credentials, absence of role-based access control (RBAC), and binding MongoDB to all network interfaces without firewall restrictions.
• Verbose error messages returned from Express handlers or MongoDB drivers that disclose collection names, field structures, or internal paths useful for further exploitation.
• Insecure direct object references (IDOR) where user-supplied identifiers (e.g., userId) are used directly in MongoDB queries without verifying that the requesting user has permission to access that resource.

These issues collectively expand the unauthenticated attack surface that tools like middleBrick scan, which tests authentication, BOLA/IDOR, property authorization, input validation, and data exposure in parallel. For example, a route like GET /users/:id that directly constructs { _id: req.params.id } without validation or ownership checks can enable IDOR, allowing one user to read or modify another user’s data. Similarly, missing rate limiting may permit enumeration attacks against usernames or emails via timing differences or error message variations.

middleBrick’s checks for Input Validation, Authorization, and Data Exposure are particularly relevant here, as they surface risky patterns such as unfiltered query construction, missing authentication on administrative endpoints, and responses that include sensitive data. Because Express does not enforce schema-level constraints by default, developers must explicitly design queries and responses to avoid leaking data or exposing injection paths to MongoDB.

Remediation focuses on strict input validation, principle of least privilege for MongoDB access, and defensive coding patterns in Express handlers. Below are concrete, safe examples.

1. Validate and sanitize route parameters

Use a validation library to enforce expected formats and reject unexpected operators.

const { body, param, validationResult } = require('express-validator');

app.get('/users/:id', [
  param('id').isMongoId().withMessage('Invalid ObjectId'),
  (req, res, next) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).json({ errors: errors.array() });
    }
    next();
  },
], async (req, res) => {
  const userId = req.params.id;
  const user = await db.collection('users').findOne({ _id: new ObjectId(userId), tenantId: req.tenantId });
  if (!user) {
    return res.status(404).json({ message: 'Not found' });
  }
  res.json(user);
});

2. Enforce tenant isolation and ownership checks

Always include tenant or owner identifiers in queries to prevent IDOR across users or organizations.

const ObjectId = require('mongodb').ObjectId;

app.get('/documents/:documentId', async (req, res) => {
  const documentId = req.params.documentId;
  const userId = req.user.id; // from authenticated session

  const document = await db.collection('documents').findOne({
    _id: new ObjectId(documentId),
    ownerId: userId,
  });

  if (!document) {
    return res.status(403).json({ message: 'Forbidden' });
  }
  res.json(document);
});

3. Apply least-privilege MongoDB connection

Configure the MongoDB connection string and user roles to grant only necessary operations per environment.

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

const uri = process.env.MONGODB_URI; // e.g., mongodb+srv://user:[email protected]/appdb?authSource=admin
const client = new MongoClient(uri, {
  serverSelectionTimeoutMS: 5000,
});

async function connect() {
  await client.connect();
  const db = client.db('appdb');
  // Use a dedicated user with roles like readWrite on appdb only
  const collections = await db.dbAdmin().listCollections({ name: 'users' }).toArray();
  // Proceed with scoped operations
}
connect().catch(console.error);

4. Disable server-side JavaScript evaluation

Ensure MongoDB is configured to reject operators that evaluate JavaScript, such as $where and $eval, which are common vectors for injection when misconfigured.

// Application-level safeguard: reject queries containing $where or $eval
app.use((req, res, next) => {
  const body = req.body || {};
  const query = req.query || {};
  if ((body.$where || body.$eval) || (query.$where || query.$eval)) {
    return res.status(400).json({ message: 'Invalid query' });
  }
  next();
});

5. Control error disclosure

Avoid exposing stack traces or MongoDB internal details in production. Use consistent error formats and log securely.

app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ message: 'Internal server error' });
});