Broken Access Control in Koa with Firestore

Broken Access Control occurs when API endpoints fail to enforce proper authorization checks, allowing one user to act on another user's resources. In a Koa application that uses Google Firestore as the backend database, this risk is amplified by a mismatch between application-level routing and Firestore security rules, and by the tendency to rely on the client for identity context.

Koa is a minimalistic Node.js framework that does not include authorization primitives by default. If route handlers directly map incoming requests to Firestore queries using identifiers taken from the request (such as a user ID in the URL path or query parameters) without validating that the authenticated subject owns that identifier, the application becomes vulnerable to BOLA/IDOR-style attacks. For example, an endpoint like /users/:userId/profile that passes userId directly into a Firestore query can be manipulated by changing the URL to access another user's profile.

Firestore security rules are evaluated independently from application code, which introduces a second vector. Developers may assume that route-level checks are sufficient and write permissive rules (e.g., allowing read/write if a user ID matches any document in a collection). If the Koa handler does not re-enforce ownership checks before issuing reads or writes, malicious actors can exploit weak or misconfigured rules to traverse the data model. This is especially risky when indexes or collection group queries are used, because a broader rule can unintentionally expose documents beyond the intended scope.

Another contributing factor is unauthenticated or loosely authenticated access to Firestore. If service accounts or API keys used by the Koa backend have overly broad IAM permissions, a compromised token or misconfigured environment can allow an attacker to issue queries across the entire database. Firestore's flexible query capabilities also mean that an attacker can probe for data patterns, infer the existence of other users' records, and combine this with ID manipulation to achieve horizontal privilege escalation.

These issues map to OWASP API Top 10 API1:2023 Broken Object Level Authorization and can lead to unauthorized profile access, data modification, or lateral movement across tenant boundaries. Real-world techniques like IDOR parameter tampering or collection group enumeration can be used to validate whether a given Firestore path is accessible, and tools like middleBrick can detect these misconfigurations by scanning the unauthenticated attack surface and correlating spec definitions with runtime behavior.

To secure a Koa application with Firestore, enforce ownership checks in both application logic and Firestore security rules, and avoid trusting client-provided identifiers for access decisions.

1. Use authenticated subject identity, not route parameters
Derive the user identity from the authentication layer (e.g., session or JWT) and use it to scope queries. Do not rely on :userId from the URL to decide what data to fetch.

// Good: derive identity from auth context, not URL parameters
const getUserProfile = async (ctx) => {
  const authUser = ctx.state.user; // authenticated subject from middleware
  if (!authUser) { ctx.status = 401; return; }
  const userDoc = await db.collection('users').doc(authUser.uid).get();
  if (!userDoc.exists) { ctx.status = 404; return; }
  ctx.body = userDoc.data();
};

2. Enforce ownership in Firestore rules
Define rules that scope reads and writes to documents where the document ID matches the authenticated user's UID. Combine this with strict request validation.

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

3. Combine server-side UID mapping with strict validation
In the Koa handler, map the authenticated UID to a known document path and avoid any dynamic concatenation of client input into Firestore paths.

// Good: explicit mapping, no concatenation of user input into document references
const updateSettings = async (ctx) => {
  const authUser = ctx.state.user;
  if (!authUser) { ctx.status = 401; return; }
  const settingsRef = db.collection('users').doc(authUser.uid).collection('settings').doc('app');
  const updates = ctx.request.body;
  await settingsRef.set(updates, { merge: true });
  ctx.status = 204;
};

4. Avoid collection group queries that bypass ownership
If you must use collection group queries, add explicit UID filters and ensure the security rules complement the query constraints.

// Good: include UID filter even when using collection group
const searchUserItems = async (ctx) => {
  const authUser = ctx.state.user;
  if (!authUser) { ctx.status = 401; return; }
  const snapshot = await db.collectionGroup('items')
    .where('uid', '==', authUser.uid)
    .get();
  ctx.body = snapshot.docs.map(d => d.data());
};

For ongoing governance, middleBrick’s Pro plan supports continuous monitoring and can be integrated into CI/CD pipelines via the GitHub Action to fail builds if risk scores degrade. Its MCP Server allows you to scan APIs directly from your AI coding assistant, helping catch misconfigurations early while you develop.