Vulnerable Components in Express with Firestore

Using Express with Google Cloud Firestore can introduce risks when application logic, data access patterns, and Firestore permissions are not carefully designed. A common vulnerability pattern occurs when Express routes directly construct Firestore queries using user-supplied input without validation or canonicalization. For example, an attacker may manipulate query parameters to target arbitrary document IDs or collections, enabling access to data that should be restricted.

Firestore security rules are intended to enforce access control, but rules that are permissive or incorrectly scoped can be bypassed when Express code does not enforce its own authorization checks. Consider an Express route that reads a document using an ID provided in the request parameters: if the route does not verify that the authenticated user has permission to view that document, the request relies solely on Firestore rules. If those rules are misconfigured, sensitive data can be exposed.

Another risk arises from how Firestore handles field-level access and metadata. An Express endpoint that returns entire Firestore documents may inadvertently expose sensitive fields such as internal identifiers, roles, or pointers to other sensitive resources. This is especially relevant when combined with Insecure Direct Object References (IDOR) and Broken Access Control (BOLA), which are common in API security findings from middleBrick scans.

Additionally, Firestore queries that lack proper indexing or use inequality filters on multiple fields can lead to performance issues or unexpected data exposure when used in high-concurrency Express applications. Attackers may craft requests that trigger inefficient queries or cause the application to return larger data sets than intended. The combination of dynamic query construction in Express and Firestore’s flexible data model increases the surface for logic flaws.

Real-world attack patterns such as prototype pollution or injection can sometimes be chained when input is used to build Firestore document paths. For instance, if an Express route uses user input to concatenate collection and document names without strict validation, an attacker might attempt path traversal or unexpected namespace access. middleBrick detects these patterns under BOLA/IDOR and Property Authorization checks, highlighting how unvalidated input can lead to privilege escalation or data exposure.

Excessive data exposure is also a concern when Firestore documents contain nested objects or arrays that are returned in full. An Express route that does not selectively project fields may disclose sensitive information in API responses. This aligns with Data Exposure findings, where middleBrick identifies endpoints that return more data than necessary and provides remediation guidance on field-level filtering.

To secure Express applications that interact with Firestore, apply strict input validation, enforce authorization at both the application and database layers, and use least-privilege Firestore rules. Below are concrete code examples demonstrating secure patterns.

1. Validate and sanitize input before querying Firestore

Always validate and sanitize user input before using it in Firestore queries. Use a validation library to enforce expected formats and reject unexpected characters or paths.

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

app.get('/users/:userId/posts', [
  validationResult({ request: { params: { userId: /^[a-zA-Z0-9_-]+$/ } } })
], async (req, res) => {
  const errors = validationResult(req);
  if (!errors.isEmpty()) {
    return res.status(400).json({ errors: errors.array() });
  }
  const userId = req.params.userId;
  const posts = await db.collection('users').doc(userId).collection('posts').orderBy('createdAt', 'desc').limit(10).get();
  res.json(posts.docs.map(d => d.data()));
});

2. Enforce ownership and authorization in route logic

Do not rely solely on Firestore security rules for per-request authorization. Confirm that the authenticated user owns or is permitted to access the target resource before querying.

const auth = require('basic-auth');

app.get('/documents/:docId', async (req, res) => {
  const user = auth(req);
  if (!user) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  const docId = req.params.docId;
  const docRef = db.collection('documents').doc(docId);
  const doc = await docRef.get();
  if (!doc.exists) {
    return res.status(404).json({ error: 'Not found' });
  }
  const data = doc.data();
  if (data.ownerId !== user.name) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  res.json(data);
});

3. Use Firestore security rules as a defensive layer

Define rules that enforce ownership and scope access narrowly. These rules complement Express checks and reduce the risk of misconfiguration exploits.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /documents/{documentId} {
      allow read, write: if request.auth != null && request.auth.uid == request.resource.data.ownerId;
    }
  }
}

4. Apply field-level filtering and avoid returning entire documents

Select only the fields you need and avoid exposing internal metadata. This reduces the impact of any accidental exposure.

app.get('/ profiles/:profileId', async (req, res) => {
  const profileRef = db.collection('profiles').doc(req.params.profileId);
  const snap = await profileRef.get({ fields: ['displayName', 'avatarUrl'] });
  if (!snap.exists) {
    return res.status(404).json({ error: 'Not found' });
  }
  res.json(snap.data());
});

5. Use parameterized collection names and avoid dynamic path concatenation

Avoid building paths from user input. If dynamic collections are necessary, strictly map input to an allowlist.

const allowedCollections = new Set(['public', 'archive']);
app.get('/data/:collectionId/doc/:docId', async (req, res) => {
  const { collectionId, docId } = req.params;
  if (!allowedCollections.has(collectionId)) {
    return res.status(400).json({ error: 'Invalid collection' });
  }
  const doc = await db.collection(collectionId).doc(docId).get();
  res.json(doc.exists ? doc.data() : {});
});

By combining input validation, explicit authorization checks, least-privilege Firestore rules, and careful data exposure practices, Express applications can safely leverage Firestore while reducing the likelihood of IDOR, BOLA, and data exposure findings that middleBrick would report.