Broken Access Control in Nestjs with Firestore

Broken Access Control occurs when authorization checks are missing, incomplete, or bypassed, allowing a user to access resources or perform actions they should not. In a NestJS application that uses Google Cloud Firestore as the backend data store, this risk is amplified when security rules and application-level checks are not aligned, or when the backend trusts client-supplied identifiers such as user IDs or resource paths.

Consider a typical setup where NestJS controllers call Firestore via the Admin SDK or a service layer. If endpoints accept a resource identifier (e.g., a document ID or path segment representing a user profile or record) and directly build a Firestore reference without confirming that the authenticated subject has permission to access that reference, the access control boundary is effectively missing. For example, an endpoint like /users/:userId/profile that constructs a Firestore document path as users/${userId}/profile based solely on route parameters allows horizontal privilege escalation: User A can change userId in the request to User B and access or modify another user’s profile if the backend does not validate ownership or role.

Firestore security rules provide a critical layer, but they are not a substitute for application-level authorization in NestJS. Rules are evaluated at the database level and can restrict reads/writes based on request auth variables and document content. However, if the NestJS backend uses the Admin SDK (which bypasses Firestore security rules), any access control implemented in rules is ignored. This means authorization must be enforced in NestJS code, typically by loading the user’s roles or permissions and validating them against the target resource before performing any Firestore operation. Common pitfalls include:

• Not validating that the authenticated user owns or is permitted to access a resource identified by an ID in the URL or request body.
• Using Firestore queries that return documents without filtering by the user’s tenant or organization, enabling IDOR across tenants.
• Exposing Firestore document references or paths in client responses, which can be manipulated to probe other data sets.

Additionally, Firestore’s query model can inadvertently expose data if queries do not include strict filters on ownership or group membership. For instance, a query that retrieves documents by a field like workspaceId must also ensure the requesting user is a member of that workspace, otherwise an attacker can iterate or guess valid workspace IDs to access data across workspaces (BOLA/IDOR). These issues map directly to OWASP API Top 10 A01:2023 Broken Access Control and can lead to unauthorized read/write of sensitive records, violating compliance frameworks such as GDPR and SOC2.

Remediation centers on enforcing authorization checks in NestJS before forming Firestore operations, and designing Firestore queries and rules that respect tenant and ownership boundaries. Below are focused patterns and code examples for NestJS with Firestore.

1. Always resolve resource ownership on the server

Do not trust route parameters to identify the resource owner. After authentication, load the user’s identity and verify access before performing any read or write. Example using the Admin SDK within a NestJS service:

import { Injectable, ForbiddenException } from '@nestjs/common';
import { getFirestore, doc, getDoc, updateDoc } from 'firebase-admin/firestore';

@Injectable()
export class ProfileService {
  private db = getFirestore();

  async updateUserProfile(userId: string, dto: { displayName: string }, requestingUserId: string) {
    if (userId !== requestingUserId) {
      throw new ForbiddenException('Cannot modify another user profile');
    }
    const ref = doc(this.db, 'users', userId, 'profile', 'settings');
    const snap = await getDoc(ref);
    if (!snap.exists()) {
      throw new ForbiddenException('Profile not found or access denied');
    }
    await updateDoc(ref, dto);
    return { success: true };
  }
}

The check userId !== requestingUserId enforces ownership at the application layer, which complements Firestore rules and prevents horizontal IDOR even if the Admin SDK is used.

2. Scope Firestore queries by user or tenant

When querying collections, always include filters that bind results to the requesting user or tenant. For example, retrieving a user’s documents within a workspace should include both workspace membership and ownership checks:

import { collection, query, where, getDocs } from 'firebase-admin/firestore';

@Injectable()
export class DocumentService {
  private db = getFirestore();

  async listDocuments(workspaceId: string, userId: string) {
    // Ensure user is a member of the workspace (check a membership collection)
    const membershipRef = doc(this.db, 'workspaces', workspaceId, 'members', userId);
    const memberSnap = await getDoc(membershipRef);
    if (!memberSnap.exists()) {
      throw new ForbiddenException('User is not a member of this workspace');
    }
    // Query scoped to workspace and explicitly include ownership or ACL fields
    const q = query(
      collection(this.db, 'documents'),
      where('workspaceId', '==', workspaceId),
      where('ownerId', '==', userId)
    );
    const snapshot = await getDocs(q);
    return snapshot.docs.map(d => ({ id: d.id, ...d.data() }));
  }
}

This prevents BOLA/IDOR by ensuring the query only returns documents the user is explicitly allowed to see, rather than relying on Firestore rules alone.

3. Use Firestore security rules as a safety net, not the primary control

If using the Admin SDK in NestJS, rules are bypassed; therefore, do not rely on rules for access decisions when the Admin SDK is in play. If you must use client SDKs in some flows, structure rules to enforce ownership and tenant checks:

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

In NestJS, prefer the Admin SDK for privileged operations but enforce the same logical checks in code to maintain consistency across client and server paths.

4. Avoid exposing Firestore references or paths to clients

Do not return raw document paths or references in API responses. Instead, return opaque identifiers or transform references into safe DTOs. This reduces the risk of clients manipulating paths to probe other data.

By combining server-side ownership validation, scoped queries, and disciplined use of Firestore rules, the risk of Broken Access Control in NestJS with Firestore is substantially reduced while preserving the flexibility and scalability of the backend.