Insecure Direct Object Reference in Chi with Firestore

Insecure Direct Object Reference (BOLA/IDOR) occurs when an API exposes a reference to an internal object—such as a Firestore document ID—and allows an authenticated user to access or modify that object without verifying authorization. In Chi, a common Go HTTP router, route parameters often map directly to Firestore document IDs. If handlers use the parameter value to build a Firestore path without checking whether the requesting user has permission to access that document, the endpoint becomes vulnerable to IDOR.

Consider a Chi route like /users/{userID}/profile. A handler might extract userID from the URL and construct a Firestore reference such as client.Collection("users").Doc(userID). If the handler returns that document directly, an attacker can change userID to another valid document ID and read or write data belonging to other users. This is a classic BOLA/IDOR. Firestore security rules can reduce risk, but they are not a substitute for server-side authorization checks at the application layer.

In a black-box scan, middleBrick tests this attack surface by submitting unauthenticated or low-privilege requests with modified object identifiers and checking whether unauthorized data is returned. With OpenAPI/Swagger spec analysis, middleBrick cross-references spec definitions with runtime findings to highlight endpoints where path parameters map to sensitive Firestore document references without proper authorization checks. Attack patterns such as parameter tampering and horizontal privilege escalation are relevant here, and findings may align with OWASP API Top 10 (2023) A01: Broken Object Level Authorization.

Firestore-specific factors can increase the likelihood of IDOR in Chi. For example, predictable document IDs, missing ownership checks, and overly permissive rules that allow read or write based solely on document path enable abuse. Firestore does not understand application-level permissions; it enforces rules at the database level. If those rules are coarse or absent, Chi handlers must enforce fine-grained authorization before issuing any Firestore operation. middleBrick’s LLM/AI Security checks do not apply to this risk, but its standard BOLA/IDOR testing validates whether object references are safely isolated between users.

To illustrate, a vulnerable Chi handler might look like this, where the ID from the route is used directly without verifying ownership:

import (
    "context"
    "net/http"

    "github.com/go-chi/chi/v5"
    "cloud.google.com/go/firestore"
)

func getUserProfile(w http.ResponseWriter, r *http.Request) {
    userID := chi.URLParam(r, "userID")
    ctx := r.Context()

    client, err := firestore.NewClient(ctx, "my-project")
    if err != nil {
        http.Error(w, "internal error", http.StatusInternalServerError)
        return
    }
    defer client.Close()

    docRef := client.Collection("users").Doc(userID)
    docSnap, err := docRef.Get(ctx)
    if err != nil {
        http.Error(w, "not found", http.StatusNotFound)
        return
    }
    // No check whether the requesting user is allowed to view this userID
    // This is a BOLA/IDOR issue
    _ = docSnap.Data()
}

An attacker who changes the userID in the URL can enumerate or tamper with other users’ profiles. Even when Firestore rules restrict access, missing server-side authorization in Chi can still lead to unauthorized data exposure.

Remediation for BOLA/IDOR in Chi with Firestore centers on enforcing authorization for every object reference. Always validate that the authenticated user is permitted to access the requested Firestore document before performing read, write, or delete operations. Use the authenticated subject’s identity—typically from session tokens, JWTs, or your auth provider—to scope queries.

A secure handler verifies ownership or role-based access before constructing the Firestore reference. For example, if your application identifies users by a UID stored in the request context or JWT, compare that UID to the document ID or a field within the document:

import (
    "context"
    "net/http"

    "github.com/go-chi/chi/v5"
    "cloud.google.com/go/firestore"
)

func getUserProfile(w http.ResponseWriter, r *http.Request) {
    userID := chi.URLParam(r, "userID")
    ctx := r.Context()

    // Obtain the authenticated user ID from your auth middleware
    authUserID := ctx.Value("authUserID") // replace with your actual auth extraction
    if authUserID == nil || authUserID != userID {
        http.Error(w, "forbidden", http.StatusForbidden)
        return
    }

    client, err := firestore.NewClient(ctx, "my-project")
    if err != nil {
        http.Error(w, "internal error", http.StatusInternalServerError)
        return
    }
    defer client.Close()

    docRef := client.Collection("users").Doc(userID)
    docSnap, err := docRef.Get(ctx)
    if err != nil {
        http.Error(w, "not found", http.StatusNotFound)
        return
    }
    _ = docSnap.Data()
}

When ownership is not based on document ID equality, scope queries using the authenticated UID. For example, if user data is stored under users/{userID} but you also have a userRoles collection, enforce access rules by querying with a where clause that includes the UID:

func listUserPosts(w http.ResponseWriter, r *http.Request) {
    userID := chi.URLParam(r, "userID")
    ctx := r.Context()

    authUserID := ctx.Value("authUserID")
    if authUserID == nil || authUserID != userID {
        http.Error(w, "forbidden", http.StatusForbidden)
        return
    }

    client, err := firestore.NewClient(ctx, "my-project")
    if err != nil {
        http.Error(w, "internal error", http.StatusInternalServerError)
        return
    }
    defer client.Close()

    postsRef := client.Collection("users").Doc(userID).Collection("posts")
    iter := postsRef.Where("userID", "==", userID).Documents(ctx)
    _, err = iter.GetAll()
    if err != nil {
        http.Error(w, "error fetching posts", http.StatusInternalServerError)
        return
    }
    // Process posts safely with ownership ensured
    _ = iter
}

For broader role-based access, maintain a mapping in Firestore (e.g., userRoles/{userID}) and check roles before allowing operations. middleBrick’s BFLA/Privilege Escalation checks can help identify whether endpoints allow privilege escalation via object references. Remember that Firestore rules should complement, not replace, these application-level checks.

middleBrick’s dashboard can track your security scores over time, and the CLI (middlebrick scan <url>) can be integrated into scripts to detect IDOR and other findings. The GitHub Action adds API security checks to your CI/CD pipeline, failing builds if risk scores exceed your threshold. The MCP Server enables scanning APIs directly from AI coding assistants within your IDE.