Broken Access Control in Grape with Firestore

Broken Access Control occurs when API endpoints fail to enforce proper authorization checks, allowing one user to access or modify another user’s resources. Using the Grape micro-framework with Google Cloud Firestore can unintentionally expose this vulnerability when route-level protections are omitted and Firestore security rules are treated as the sole authorization mechanism.

Grape is a REST-like API framework for Ruby that lets you define endpoints, parameters, and helpers without built-in authorization. Developers sometimes assume Firestore security rules (which protect data at the database level) are enough to prevent unauthorized access. However, rules are not a substitute for application-layer authorization in Grape. If a Grape endpoint directly uses a user-supplied identifier (such as user_id) to construct a Firestore document path or query, and does not verify that the authenticated subject has the right to access that path, an attacker can manipulate the identifier to access other users’ data.

Consider a typical pattern: an endpoint like /users/:user_id/profile retrieves a profile document from a profiles collection using the user_id parameter. Without explicit authorization checks in Grape, an attacker can change :user_id to another user’s ID and read or overwrite sensitive fields. Firestore rules may allow the operation if the request includes an ID token and the document exists, but they do not automatically enforce that the authenticated user’s UID matches the requested user_id. This mismatch between route parameter handling and data ownership is a common root cause of Broken Access Control in Grape with Firestore.

Additionally, over-permissive Firestore rules can amplify the risk. For example, a rule that permits read/write if request.auth != null but does not scope data to the user’s own document enables horizontal privilege escalation. When combined with missing ownership checks in Grape, this allows an authenticated user to iterate over possible IDs and enumerate accessible records. Such combinations also intersect with BOLA/IDOR findings, which are often surfaced by middleBrick scans that test unauthenticated attack surfaces and compare spec definitions with runtime behavior.

To fix Broken Access Control when using Grape and Firestore, enforce ownership checks in the API layer before performing any Firestore operation. Never rely on Firestore security rules alone to guarantee that a user can only access their own data. Below are concrete, realistic code examples that demonstrate proper authorization patterns.

1. Enforce UID ownership in the Grape endpoint

Always resolve the authenticated user’s UID from the request (e.g., from the JWT or session) and ensure it matches the requested resource’s owner. Do not trust route parameters without validation.

# Gemfile: gem 'google-cloud-firestore'
require 'google/cloud/firestore'
require 'grape'

class ProfileResource < Grape::API
  helpers do
    def current_user_uid
      # Example: extract UID from an Authorization header token
      header = env['HTTP_AUTHORIZATION']
      return nil unless header&.start_with?('Bearer ')
      token = header.split(' ').last
      # Verify and decode the token using your auth provider
      # This is pseudocode; use your actual ID token verification
      decoded = decode_id_token(token)
      decoded['uid']
    end

    def firestore
      @firestore ||= Google::Cloud::Firestore.new
    end
  end

  before do
    error!('Unauthorized', 401) unless current_user_uid
  end

  desc 'Get user profile'
  params do
    requires :user_id, type: String, desc: 'The profile user ID'
  end
  get '/users/:user_id/profile' do
    requested_uid = params['user_id']
    current_uid = current_user_uid

    # Critical: ensure the requesting user owns the resource
    error!('Forbidden', 403) unless current_uid == requested_uid

    doc_ref = firestore.doc("profiles/#{requested_uid}")
    snapshot = doc_ref.get
    error!('Not found', 404) unless snapshot.exists?

    { user_id: requested_uid, profile: snapshot.data }
  end
end

2. Use Firestore queries scoped to the authenticated UID

When listing or searching documents, always scope queries to the authenticated user to prevent enumeration across other users’ data. Avoid queries that rely only on rules to filter by owner.

  desc 'List user-owned items'
  get '/users/:user_id/items' do
    current_uid = current_user_uid
    requested_uid = params['user_id']

    error!('Forbidden', 403) unless current_uid == requested_uid

    items_ref = firestore.collection('items')
    query = items_ref.where(:owner_uid, '==', requested_uid)
    results = query.get.map { |doc| { id: doc.id, data: doc.data } }

    { items: results }
  end
end

3. Combine with Firestore rules for defense in depth

While the application layer must enforce ownership, keep Firestore rules as a safety net. Use rules that require the request UID to match document fields, and avoid broad allow-read/when true patterns.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /profiles/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    match /items/{itemId} {
      allow read, write: if request.auth != null && request.auth.uid == request.resource.data.owner_uid;
    }
  }
}

4. Avoid unsafe deserialization and mass assignment

When writing data to Firestore, explicitly whitelist fields instead of passing raw user input. This prevents attackers from injecting or modifying fields such as owner_uid or administrative flags.

  params do
    requires :name, type: String
    requires :email, type: String
  end
  post '/users/:user_id/profile' do
    current_uid = current_user_uid
    requested_uid = params['user_id']
    error!('Forbidden', 403) unless current_uid == requested_uid

    # Explicitly map allowed fields instead of using params directly
    profile_data = {
      name: params['name'],
      email: params['email'],
      updated_at: Time.now.utc
    }

    firestore.doc("profiles/#{requested_uid}").set(profile_data)
    { status: 'updated' }
  end
end

These patterns ensure that authorization is enforced consistently in Grape and that Firestore operations are scoped to the authenticated user’s data. By validating ownership in the API layer and using scoped queries, you reduce the risk of Broken Access Control while maintaining compatibility with Firestore’s security model.