Insecure Design in Chi with Firestore

Insecure Design in the context of Chi and Firestore often arises from how Firestore rules and data models are structured, and how Chi routes and handlers interact with those rules. Firestore is a NoSQL document database that relies on security rules to enforce access control and validation at read/write time. When application logic in Chi does not properly validate authorization before issuing Firestore operations, or when Firestore rules are written with overly permissive conditions, the attack surface expands.

One common pattern is defining Firestore rules that scope reads and writes to a user ID derived from authentication claims, but implementing the Chi endpoint without confirming that the requesting user is authorized to operate on the targeted document. For example, a route like /users/:userId/preferences might extract userId from the URL and directly pass it to Firestore without verifying that the authenticated subject matches userId. This design flaw enables IDOR-like access because the server trusts the client-supplied identifier.

Firestore’s rule syntax supports map and array operations, which can inadvertently expose sensitive subcollections if rules are not explicit about which paths are readable or writable. A rule such as allow read: if true; on a collection group intended for administrative use can expose logs or configuration documents to unauthenticated or low-privilege callers when combined with a Chi endpoint that enumerates documents without additional checks. Similarly, using wildcard operations in rules without tight constraints can allow broader access than intended, especially when Chi endpoints perform batch reads or exports based on query parameters supplied by the client.

Another dimension of insecure design involves data modeling choices in Firestore that increase risk when combined with Chi handlers. Denormalized data and composite indexes can simplify reads in Chi, but they also multiply the impact of misconfigured rules. If a Chi service aggregates data from multiple collections to construct a response, and one of those collections has a weak rule, the aggregated view may disclose information that should remain isolated. Additionally, Firestore transactions and batched writes executed from Chi must ensure that each operation respects the same authorization logic; omitting checks in any step can lead to privilege escalation or data leakage.

LLM/AI Security considerations also intersect with insecure design when Firestore stores prompts, model outputs, or configuration used by AI features in Chi. If Firestore documents containing system prompts or sensitive metadata are readable due to broad rules, and a Chi endpoint exposes an endpoint that returns these documents based on user input, the design may facilitate prompt extraction or data exfiltration. Ensuring that security checks are applied consistently across Firestore rules and Chi route logic is essential to prevent these cross-layer vulnerabilities.

Remediation focuses on aligning Firestore security rules with explicit authorization checks in Chi handlers, and adopting data modeling and query practices that limit exposure. Always validate that the authenticated subject matches the resource they intend to access before performing reads, writes, or deletes.

Chi route with user-context validation

In Chi, extract identity from the request context and use it to scope Firestore queries. Avoid using client-provided identifiers as the sole source of authorization.

;; src/handler/users.clj
(ns myapp.handler.users
  (:require [cheshire.core :as json]
            [clj-http.client :as http]
            [taoensso.timbre :as log]))

(defn get-user-preferences [req db]
  (let [uid (get-in req [:session :uid])] ; subject derived from authenticated session
    (when (not= uid (some-> req :params :userId)))
      {:status 403 :body (json/generate-string {:error "forbidden"})}
      (let [doc (some-> (str "users/" uid "/preferences")
                        (.get db))]
        {:status 200 :body (or (some-> doc :data json/generate-string) "{}")}))))

(def app
  (-> (ring.middleware.json/wrap-json-body (fn [req] (get-user-preferences req *db*)))
      (ring.middleware.keyword-params/wrap-keyword-params)
      (ring.middleware.params/wrap-params)))

The example ensures the authenticated user ID matches the resource path and does not rely on the URL parameter alone. The Firestore document read is scoped to the user's own document.

Firestore rule scoping and validation

Rules should explicitly bind the requesting user to document fields and avoid wildcards that broaden access unintentionally.

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 /preferences/{docId} {
        allow read, write: if request.auth != null && request.auth.uid == userId;
      }
    }
    match /admin/configs/{configId} {
      allow read: if request.auth != null && request.auth.token.admin == true;
      allow write: if request.auth != null && request.auth.token.admin == true;
    }
  }
}

These rules enforce ownership for user documents and restrict administrative collections to privileged claims, reducing the risk of IDOR and privilege escalation when Chi endpoints query these paths.

Batch operations and transaction safety

When Chi performs batched reads or writes, ensure each operation is gated by the same ownership checks. Avoid constructing queries that pull entire collections based on unfiltered client input.

;; Example batched read scoped to user-owned documents
(defn user-owned-collections [db uid]
  (->> (str "users/" uid "/items")
       (.collection db)
       (.get)
       :docs
       (mapv #(hash-map :id (:document-id %)
                        :data (:data %)))))

Limit the use of collection group reads to well-defined use cases and tightly bound rules. Prefer explicit paths in Chi handlers to keep authorization logic visible and testable.

Data modeling and index hygiene

Avoid storing sensitive metadata that should not be enumerated. If Chi aggregates data from multiple subcollections, ensure each subcollection rule restricts access to the owning user or role. Prefer server-side field masking in Chi rather than exposing raw Firestore documents directly to downstream consumers.