Identification Failures in Chi with Firestore

Identification failures occur when an application fails to properly identify and authenticate entities before allowing access to resources. In Chi, a common Haskell web framework, handling identifiers such as document IDs from Firestore without rigorous validation and authorization checks can lead to Insecure Direct Object References (IDOR) and Broken Object Level Authorization (BOLA). Firestore uses paths like projects/{project}/databases/(default)/documents/{collection}/{document} to reference documents; if these identifiers are exposed through URLs or API parameters without ensuring the requesting subject is authorized for that specific document, attackers can manipulate identifiers to access or modify other users’ data.

Chi routes typically extract identifiers from path parameters. For example, a route like /users/:userId/documents/:documentId might pass these values directly into Firestore get or update calls. If the server does not verify that the authenticated subject has permission for the provided userId and documentId, the unauthenticated or low-privilege actor can enumerate or guess IDs. Because Firestore enforces security rules at the document level, missing authorization checks in application logic effectively bypass intended access controls, exposing data confidentiality and integrity.

Chi applications that rely on Firestore for storage must treat identifiers as untrusted inputs. An attacker can modify numeric or string identifiers in requests to access neighboring records (ID enumeration), escalate by targeting administrative collections, or exploit predictable IDs to perform mass data scraping. This becomes more impactful when Firestore security rules are misconfigured to allow broad read or write access at the collection level, expecting application-layer checks to enforce per-document authorization. Without proper identification and authorization checks in Chi handlers, Firestore rules alone cannot prevent unauthorized access, as the application may leak document references in responses or logs.

Another angle involves session and subject identification. Chi applications sometimes store user identifiers in cookies or JWTs; if these tokens are not validated and bound to Firestore document access patterns, an attacker can reuse or tamper with identifiers to assume another identity. Firestore does not inherently understand application session semantics, so the onus is on Chi to map authenticated subjects to allowed document paths and enforce this mapping on every request. Missing or weak identification controls here can lead to horizontal privilege escalation across user boundaries, a core aspect of BOLA/IDOR as covered in middleBrick’s scans.

Insecure Consumption patterns also intersect with identification failures. If a Chi service deserializes Firestore document payloads into generic JSON or Haskell data structures without validating identifiers and access rights, it may inadvertently expose internal references or allow injection of malicious identifiers. middleBrick’s checks for Identification Failures include testing whether endpoints properly validate identifiers, apply per-request authorization, and avoid leaking references in error messages or logs. These tests highlight risks when Firestore paths are constructed from user-supplied data without strict allowlisting and ownership verification.

Remediation centers on ensuring every Firestore operation in Chi is preceded by explicit identification and authorization checks, using the authenticated subject to constrain accessible document paths. Do not rely on Firestore security rules alone to enforce per-document access; enforce it in application logic within Chi handlers.

{-# LANGUAGE OverloadedStrings #-}
import qualified Data.Text as T
import Network.Wai (requestHeaders)
import Network.HTTP.Types (status403)
import qualified Database.Firestore as FS

-- A helper to extract the authenticated user ID from request context or JWT.
extractUserId :: Request -> Maybe T.Text
extractUserId req = lookup "x-user-id" (requestHeaders req)

-- Chi handler with proper identification and ownership check.
userDocumentHandler :: FS.Client -> RouterM () 
userDocumentHandler db = do
  userId <- param "userId"
  documentId <- param "documentId"
  subjectId <- liftIO $ extractUserId =< request
  case subjectId of
    Nothing -> status status401 & json ("error" T.=> "Unauthenticated")
    Just uid -> do
      -- Critical: verify the subject owns or is allowed to access this document.
      if uid /= userId
        then status status403 & json ("error" T.=> "Forbidden: subject mismatch")
        else do
          let docPath = ["users", T.unpack userId, "documents", T.unpack documentId]
          docResult <- liftIO $ FS.get db (FS.toDocumentPath docPath)
          case docResult of
            Left err -> status status500 & json ("error" T.=> T.pack (show err))
            Right doc -> json (FS.documentContents doc)

This pattern ensures the Chi route parameter userId is compared to the authenticated subject before any Firestore operation. The document path is constructed from validated identifiers, avoiding direct concatenation of untrusted input. Firestore document reads and writes should always be gated by this ownership check, and you should avoid using wildcard or collection-group reads that bypass per-document authorization.

For broader remediation, adopt least-privilege Firestore security rules that align with the application’s ownership model, but do not consider them sufficient on their own. Rules can deny access at the database level, but Chi should still enforce rules to prevent malformed requests and reduce attack surface. Use allowlists for document ID formats (e.g., UUID or numeric patterns) and avoid exposing internal Firestore paths in API responses or client-side payloads.

middleBrick’s scans for Identification Failures include runtime tests that attempt to access documents with modified identifiers and inspect whether the application enforces ownership. If your Chi endpoints are scanned, findings will include missing authorization checks and overly permissive rules, with remediation guidance tied to OWASP API Top 10 and compliance frameworks. Consider the Pro plan for continuous monitoring so that new routes or Firestore collections are automatically assessed for identification issues after each deployment.