Security Misconfiguration in Express with Firestore

When an Express application interacts with Google Cloud Firestore, security misconfigurations often arise from a mismatch between broad Firestore IAM rules and insufficient input validation or authentication checks in the Express layer. Firestore security rules are designed to enforce access control at the database level, but if Express routes do not independently verify authorization for each request, attackers can exploit weak route handling to make unauthorized Firestore calls on behalf of users.

For example, a route like /api/users/:userId/profile that directly uses req.params.userId to construct a Firestore docRef without validating that the authenticated user owns that ID enables BOLA (Broken Object Level Authorization). Even if Firestore rules restrict reads to a user’s own documents, an Express route that fails to enforce ownership checks before referencing users/{userId} provides a path to tampered access. This commonly occurs when developers rely solely on Firestore rules while neglecting route-level authorization, effectively exposing a wider attack surface.

Another misconfiguration involves overly permissive Firestore rules combined with unvalidated input in Express handlers. If rules allow read or write access based only on request authentication and not on document structure or context, an attacker may supply nested fields or special values that bypass intended constraints. For instance, allowing a client to specify a role field in a write request and directly passing that into a Firestore set or update call can lead to privilege escalation. This is a Privilege Escalation vector where elevated permissions are assigned through manipulated input rather than server-side enforcement.

Middleware misplacement is also a concern. If CORS or body-parser configurations in Express are too permissive—such as allowing all origins or not strictly validating content types—an attacker may inject malicious requests that reach Firestore with unexpected payloads. Insecure default configurations in Express, such as disabling strict routing or enabling prototype pollution through libraries like qs, can further allow crafted inputs to traverse into Firestore operations in ways that bypass intended constraints.

Finally, unauthenticated or weakly authenticated endpoints in Express that directly expose Firestore queries—such as listing collections or documents for debugging—can lead to Data Exposure. Without proper authentication checks or rate limiting, these routes may leak sensitive document contents or reveal data structure details useful for reconnaissance, aligning with findings from the LLM/AI Security and Data Exposure checks run by middleBrick scans.

Remediation centers on enforcing strict ownership checks, validating and sanitizing all inputs, and applying principle of least privilege in both Express routes and Firestore security rules. Always authenticate and authorize on the server, and never trust client-supplied identifiers or payloads.

First, enforce user-to-document mapping in Express before any Firestore operation. Use an authenticated session to determine the user’s UID, and ensure that any ID supplied in the request aligns with that UID.

// Express route with proper ownership check
const { getFirestore, doc, getDoc } = require('firebase-admin/firestore');
const db = getFirestore();

app.get('/api/users/:userId/profile', async (req, res) => {
  const authenticatedUserId = req.user.uid; // from session/auth middleware
  const requestedUserId = req.params.userId;

  if (authenticatedUserId !== requestedUserId) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  const userDoc = await getDoc(doc(db, 'users', requestedUserId));
  if (!userDoc.exists()) {
    return res.status(404).json({ error: 'Not found' });
  }
  res.json(userDoc.data());
});

Second, validate and sanitize all inputs before using them in Firestore references or queries. Use an allowlist for expected fields and avoid directly passing client input into Firestore paths.

// Validate userId format before use
const { check, validationResult } = require('express-validator');

app.post('/api/users/:userId/update', [
  check('userId').isAlphanumeric().isLength({ min: 1, max: 20 }),
  check('displayName').isString().trim().escape()
], async (req, res) => {
  const errors = validationResult(req);
  if (!errors.isEmpty()) {
    return res.status(400).json({ errors: errors.array() });
  }

  const { userId } = req.params;
  const { displayName } = req.body;

  await getDoc(doc(db, 'users', userId)).then(snap => {
    if (!snap.exists()) {
      return res.status(404).json({ error: 'User not found' });
    }
    return snap.ref.update({ displayName });
  });
  res.json({ success: true });
});

Third, complement Express controls with tightly scoped Firestore rules that reference authenticated UID and avoid wildcards that grant broad access. Rules should tie reads and writes to the requesting user’s document path based on request.auth.uid.

// Firestore rule: users may only read/write their own document
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Fourth, restrict query inputs and disable mass assignment by explicitly specifying which fields can be written. This prevents attackers from injecting fields such as role or admin into documents.

// Explicit field update in Express
app.patch('/api/users/:userId', async (req, res) => {
  const { email, phone } = req.body;
  const userId = req.params.userId;

  // Only allow known-safe fields
  await updateDoc(doc(db, 'users', userId), {
    email: email,
    phone: phone
  });
  res.json({ success: true });
});

Finally, add defense-in-depth with Express middleware for authentication, strict CORS, and rate limiting to reduce abuse opportunities. Combine these with continuous scanning using middleBrick’s CLI or GitHub Action to detect regressions in Firestore rule and Express route configurations.