Insecure Design in Grape with Firestore

Insecure Design in a Grape API backed by Firestore often arises from trusting client-supplied identifiers and over-permissive Firestore Security Rules. Firestore rules are evaluated with the requesting user’s identity available via request.auth, but if the API does not enforce ownership checks at the route level, an attacker can manipulate resource IDs to access or modify data that belongs to other users. This is a Broken Object Level Authorization (BOLA) / IDOR pattern specific to Firestore, where the database path includes a user ID that the client can guess or enumerate.

Consider a design where a Grape endpoint uses a path parameter directly in a Firestore path without validating that the authenticated subject owns that resource. For example, an endpoint like /users/:user_id/profile might construct a Firestore document reference as users/#{params[:user_id]}/profile. If the route does not compare current_user.id with params[:user_id], an attacker can change :user_id to access another user’s profile. Firestore may still return the document if rules permit broad reads, and sensitive PII or settings could be exposed.

Another insecure pattern involves rule configurations that assume client-supplied subcollections or fields enforce isolation. Firestore rules can allow reads/writes under a collection group if conditions are too permissive (for example, allowing writes if request.resource.data.userId == request.auth.uid) while the client can forge the userId field in the request body. Because Firestore evaluates rules at write time, a malicious request can bypass intended isolation when the API does not enforce server-side ownership using the authenticated UID from the request context rather than trusting the payload.

Additionally, the combination of Firestore’s real-time listeners and Grape endpoints can inadvertently create insecure designs where clients subscribe to channels or document paths they should not see. If a Grape route exposes a Firestore document ID without validating access, and a client uses that ID to attach a listener, they may receive real-time updates for data they are not authorized to view. This design flaw extends the impact of BOLA across both request/response and streaming paths.

These issues map to OWASP API Top 10 A01:2023 Broken Access Control and can lead to unauthorized read/write access to user data. Unlike traditional SQL isolation enforced by row-level security, Firestore requires deliberate rule design and route-level checks to ensure subject-to-resource mapping is correct. middleBrick detects such BOLA/IDOR patterns during black-box scanning, highlighting risky endpoint designs and overly permissive rules that combine poorly with Grape routing logic.

To secure Grape endpoints with Firestore, enforce ownership checks on the server and design rules that align with least-privilege access. Always resolve the authenticated UID from the request context (e.g., via an auth token decoded in Grape) and use it to construct Firestore paths, rather than relying on route parameters that can be tampered with.

Example: Safe route with UID-based document path

# In your Grape endpoint
class Profiles < Grape::API
  helpers do
    def current_user
      # Assume decode_token returns { uid: 'user_abc123' } or nil
      @current_user ||= decode_token(env['HTTP_AUTHORIZATION'])
    end
  end

  before { halt 401, { error: 'Unauthorized' }.to_json unless current_user }

  get '/profile' do
    # Use server-side UID, never trust params[:user_id]
    profile_ref = Firestore::DocumentReference.new("users/#{current_user[:uid]}/profile")
    doc = profile_ref.get
    { uid: current_user[:uid], profile: doc.data }
  end
end

Firestore Security Rules aligned with server-side checks

Rules should still enforce ownership at the database level, but they complement rather than replace server-side validation. Use request.auth != null and compare request.auth.uid with document fields or path components.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{user_id}/profile {
      allow read, write: if request.auth != null && request.auth.uid == user_id;
    }
    // Avoid broad collection group reads unless truly needed; if used, constrain tightly:
    match /private/{doc=**} {
      allow read: if request.auth != null && request.auth.uid == request.resource.data.userId;
    }
  }
}

Avoid trusting client-supplied IDs in Firestore paths

Never directly interpolate route parameters into Firestore paths without verifying they match the authenticated subject. An attacker can iterate over numeric or predictable IDs to enumerate other users’ data if the API lacks ownership checks.

# Insecure pattern to avoid:
# get '/users/:user_id/settings' do
#   ref = Firestore::DocumentReference.new("users/#{params[:user_id]}/settings")
#   ref.get.data
# end

# Secure alternative:
get '/settings' do
  ref = Firestore::DocumentReference.new("users/#{current_user[:uid]}/settings")
  halt 404 if ref.get.nil?
  { settings: ref.get.data }
end

Collection Group rules with scoped conditions

If using collection groups, constrain writes to documents where the stored UID matches the authenticated UID, and avoid rules that allow writes based solely on client-supplied fields without server-side validation.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /datasets/{dataset}/records/{record} {
      // Ensure the record’s uid matches the authenticated user
      allow create: if request.auth != null && request.auth.uid == request.resource.data.uid;
      allow read, update, delete: if request.auth != null && request.auth.uid == resource.data.uid;
    }
  }
}

Defense in depth

Combine route-level ownership checks with Firestore rules and avoid exposing raw document IDs in URLs where possible. For operations that must accept client identifiers, map them server-side to canonical references and validate access before constructing Firestore requests. middleBrick’s scans can surface overly permissive rules and missing ownership checks, helping you refine both API design and Firestore security posture.