Broken Access Control in Chi with Firestore

Broken Access Control (BOLA/IDOR) in a Chi application that uses Cloud Firestore typically occurs when server-side route handlers or Firestore security rules fail to enforce identity-based authorization on document reads and writes. In Chi, route handlers are often defined as modular endpoints where a developer might read a document path like users/{userId} but only check that a request exists, not that the requesting user matches the userId in the path or in the document itself.

Firestore’s security model relies on rules that evaluate request.auth and document data. If rules are written to allow broad read or write access—for example, allowing read access to any document within a collection—or if the Chi server-side code trusts client-supplied identifiers without verifying ownership, an attacker can manipulate IDs to access other users’ data. This is a classic BOLA/IDOR pattern: tampering with an object reference (user ID in the URL or document ID) to access unauthorized resources.

Consider a Chi endpoint that retrieves a user profile using a path parameter without verifying that the authenticated user owns that profile:

import { Router } from '@hono/router';
import { getFirestore, doc, getDoc } from 'firebase-admin/firestore';

const router = Router();
router.get('/users/:userId', async (c) => {
  const userId = c.req.param('userId');
  const db = getFirestore();
  const userDoc = await getDoc(doc(db, 'users', userId));
  if (!userDoc.exists()) {
    return c.json({ error: 'Not found' }, 404);
  }
  return c.json(userDoc.data());
});

In this example, if the Chi handler does not compare userId with the authenticated user’s ID (available via request context or session), any authenticated user can enumerate or read any other user’s profile by changing the ID. Even if Firestore rules restrict reads to authenticated users, they may still permit reads across all documents in the collection, enabling mass enumeration. Such misconfigurations can expose personal data and contribute to account takeover or privacy violations.

Another common scenario involves post or resource ownership checks. For instance, a Chi handler that updates a post might extract a post ID from the URL and apply the update without confirming that the authenticated user created the post:

import { Router } from '@hono/router';
import { getFirestore, doc, updateDoc } from 'firebase-admin/firestore';

const router = Router();
router.post('/posts/:postId', async (c) => {
  const postId = c.req.param('postId');
  const body = await c.req.json();
  const db = getFirestore();
  await updateDoc(doc(db, 'posts', postId), body);
  return c.json({ ok: true });
});

If Firestore rules grant write access to authenticated users on the entire posts collection and the handler never verifies that the authenticated user ID matches the post’s owner field, an attacker can modify any post by guessing or iterating IDs. This demonstrates how server-side logic and Firestore rules must work together to enforce ownership and mitigate BOLA/IDOR.

Firestore rules alone cannot fully protect against BOLA/IDOR if the Chi server does not perform explicit authorization checks. Rules that use request.auth != null are insufficient when combined with overly permissive data structures or when the server-side code assumes client-provided identifiers are trustworthy. The combination of Chi routing, Firestore’s document-oriented model, and misaligned authorization logic creates a practical path for unauthorized data access.

To remediate Broken Access Control in Chi with Firestore, always couple route-level authorization with precise Firestore security rules. On the server side, retrieve the authenticated user ID from the request context (e.g., session or token) and explicitly compare it with resource ownership fields before performing any Firestore operation.

For the user profile endpoint, the Chi handler should verify that the authenticated user matches the requested user ID:

import { Router } from '@honn/router';
import { getFirestore, doc, getDoc } from 'firebase-admin/firestore';
import { verifySession } from '../lib/auth';

const router = Router();
router.get('/users/:userId', async (c) => {
  const userId = c.req.param('userId');
  const auth = verifySession(c); // returns { uid } or null
  if (!auth || auth.uid !== userId) {
    return c.json({ error: 'Unauthorized' }, 403);
  }
  const db = getFirestore();
  const userDoc = await getDoc(doc(db, 'users', userId));
  if (!userDoc.exists()) {
    return c.json({ error: 'Not found' }, 404);
  }
  return c.json(userDoc.data());
});

On the Firestore side, rules should still enforce ownership checks and avoid broad read or write grants. For example, allow reads only when the requesting user’s UID matches the document ID or a field within the 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;
    }
    match /posts/{postId} {
      allow read: if request.auth != null;
      allow write: if request.auth != null && request.auth.uid == request.resource.data.userId;
    }
  }
}

For the posts update scenario, the Chi handler should ensure the authenticated user owns the post, and the rule should enforce that writes set the userId field consistently:

import { Router } from '@honn/router';
import { getFirestore, doc, getDoc, updateDoc } from 'firebase-admin/firestore';
import { verifySession } from '../lib/auth';

const router = Router();
router.post('/posts/:postId', async (c) => {
  const postId = c.req.param('postId');
  const body = await c.req.json();
  const auth = verifySession(c);
  if (!auth) {
    return c.json({ error: 'Unauthorized' }, 403);
  }
  const db = getFirestore();
  const postDoc = await getDoc(doc(db, 'posts', postId));
  if (!postDoc.exists()) {
    return c.json({ error: 'Not found' }, 404);
  }
  const postData = postDoc.data();
  if (postData.userId !== auth.uid) {
    return c.json({ error: 'Forbidden' }, 403);
  }
  await updateDoc(doc(db, 'posts', postId), body);
  return c.json({ ok: true });
});

Additionally, avoid exposing internal document IDs in URLs when they can be derived from ownership metadata, or ensure that Firestore rules reject any write that attempts to change the userId field in ways that could escalate privileges. Combine least-privilege rules—scoped to user-specific paths—with server-side checks to reduce the impact of rule misconfigurations or client tampering.

When integrating with other Chi middleware, centralize authorization logic (e.g., a lightweight policy function) to ensure consistent checks across endpoints. Regularly review Firestore rules with simulated requests to confirm that read and write conditions correctly reflect the intended ownership model and that no rule allows overly permissive access at the collection or document level.