Insecure Design in Loopback with Firestore

Insecure Design in a Loopback application that uses Google Cloud Firestore typically arises from trusting client-supplied identifiers to construct document paths and from missing ownership checks at the data-access layer. Firestore’s security rules partially mitigate misuse, but rules cannot compensate for a backend that exposes internal document IDs or allows a user to iterate across collections without validating ownership.

Consider a common pattern where an endpoint accepts a documentId from the client and directly loads a Firestore document without verifying that the document belongs to the requesting user. Because Firestore paths are predictable, an attacker can manipulate the ID to access other users’ data, leading to Insecure Direct Object Reference (IDOR) or Broken Object Level Authorization (BOLA). In a Loopback backend, model datasources may be configured to use the default Firestore connector, but if authorization logic is implemented only as a Firestore rule and not also enforced in the Loopback model’s relations and ACLs, an attacker can bypass intended isolation by changing identifiers in requests.

Another design flaw is exposing Firestore document IDs in API responses. If an endpoint returns a list of resources that include document IDs, an attacker can use those IDs to probe other endpoints or combine them with known user identifiers to enumerate data. Firestore document IDs are often auto-generated but can also be client-supplied; when client-supplied IDs are used without validation, the risk of ID enumeration and injection increases.

Additionally, insufficient validation of query constraints can lead to data leakage. A Loopback filter that is naively merged with a Firestore query may allow an attacker to inject operators or fields that broaden the result set. For example, if a filter object is passed directly to the Firestore SDK without stripping or sanitizing fields like __name__ or array-contains conditions, a user may retrieve data belonging to other tenants or roles. This is an insecure design choice because the backend implicitly trusts the structure and content of the client-provided filter.

These issues are detectable by middleBrick’s BOLA/IDOR and Property Authorization checks, which analyze the OpenAPI/Swagger spec and runtime behavior to identify missing ownership validation and over-permissive data exposure. The scanner can surface findings such as unauthenticated endpoints or endpoints that accept user-controlled identifiers without verifying resource ownership, and it maps these findings to frameworks like OWASP API Top 10 and SOC2 to provide prioritized remediation guidance.

Remediation focuses on enforcing ownership checks in the Loopback application layer, avoiding reliance solely on Firestore security rules, and validating all identifiers and filters before they reach Firestore.

First, resolve the authenticated user’s identity in your Loopback middleware or controller and use it to scope every Firestore query. Instead of accepting a raw document ID from the client, derive the document reference from the authenticated user’s UID. For example, if you store user data in a subcollection, construct the path programmatically:

const firestore = new Firestore();

async function getUserData(userId, documentId) {
  // Enforce that documentId belongs to userId by building the path server-side
  const docRef = firestore
    .collection('users')
    .doc(userId)
    .collection('resources')
    .doc(documentId);

  const snapshot = await docRef.get();
  if (!snapshot.exists) {
    throw new Error('Not found');
  }
  return snapshot.data();
}

This ensures that even if an attacker supplies a different documentId, they cannot escape their own user namespace because the server always prepends the authenticated user’s UID to the path.

function buildSafeFilter(clientFilter) {
  const allowedFields = new Set(['status', 'createdAt']);
  const safe = {};
  if (clientFilter && typeof clientFilter === 'object') {
    Object.keys(clientFilter).forEach((key) => {
      if (allowedFields.has(key) && [‘==’, ‘>=', '<='].includes(clientFilter[key]?.op)) {
        safe[key] = clientFilter[key];
      }
    });
  }
  return safe;
}

// Usage with a Firestore query
const safeFilter = buildSafeFilter(req.query.filter);
let query = firestore.collection('resources').where('status', '==', 'active');
if (safeFilter.status) {
  query = query.where('status', '==', safeFilter.status.value);
}
const snapshot = await query.limit(50).get();