Broken Access Control in Sinatra with Firestore

Broken Access Control occurs when an API fails to enforce proper authorization between subjects (users or service accounts) and resources. In a Sinatra application that uses Google Cloud Firestore as the backend, the risk arises from a mismatch between authentication (verifying identity) and authorization (verifying permission to access a specific document or collection).

Sinatra is a lightweight Ruby framework that does not enforce access controls by default. If route handlers directly use request parameters to construct Firestore document paths or queries without validating caller permissions, an attacker can manipulate identifiers to access or modify data belonging to other users. For example, an endpoint like /users/:user_id/profile that retrieves a Firestore document using the supplied user_id without confirming that the authenticated subject owns that ID enables a BOLA/IDOR (Broken Level Authorization / Insecure Direct Object Reference) vulnerability.

Firestore security rules can mitigate some risks at the server side, but they are not a substitute for application-level authorization in Sinatra. If the Sinatra layer assumes a request is authorized because a session or token exists, but does not re-check ownership against Firestore document metadata (such as a uid field or IAM policy bindings), the API exposes sensitive data or allows unintended writes. Common insecure patterns include using a wildcard allow in Firestore rules while the Sinatra app does not filter by user identity, or trusting client-supplied document IDs without server-side ownership checks.

Real-world attack patterns include changing numeric or UUID parameters to enumerate other users’ data (enumeration), leveraging predictable IDs to access adjacent records, or exploiting missing index checks to read from collections where permissions are misconfigured. These map to OWASP API Top 10 A01:2023 — Broken Access Control and can lead to unauthorized data exposure or modification. Proper authorization must validate each request against the resource’s access control lists (ACLs), ownership fields, and role-based constraints before forming Firestore queries or document paths in Sinatra.

To prevent Broken Access Control when using Firestore in Sinatra, enforce authorization at the application layer before constructing queries or document references. Always resolve the subject’s identity from the request (e.g., from an ID token or session) and use that identity to scope Firestore operations, rather than relying on client-supplied parameters.

Principle 1: Bind the authenticated subject to Firestore queries

Instead of using a request parameter as the sole identifier, derive the allowed document path from the authenticated user’s UID. This ensures users can only access their own data regardless of what the URL provides.

require 'sinatra'
require "google/cloud/firestore"

before do
  content_type :json
  # Example: authenticate and verify token, then set current_user
  @current_user = verify_user_from_request(request)
end

def verify_user_from_request(request)
  # Verify an Authorization header, validate ID token, and return user identity
  # For illustration, return a mock user with uid.
  OpenStruct.new(uid: 'user-123')
end

# Safe route: scope document read to the authenticated user
get '/profile' do
  user_uid = @current_user.uid
  firestore = Google::Cloud::Firestore.new
  doc_ref = firestore.doc("users/#{user_uid}/profile")
  snapshot = doc_ref.get
  if snapshot.exists?
    snapshot.data.to_json
  else
    status 404
    { error: 'Profile not found' }.to_json
  end
end

Principle 2: Reject non‑owning requests before Firestore interaction

For endpoints that accept an identifier, compare it to the authenticated subject’s identifier and return 403 if they do not match. Do not proceed to Firestore operations when ownership cannot be confirmed.

# Safe route: explicit ownership check before querying
get '/users/:user_id/settings' do
  requested_user_id = params['user_id']
  user_uid = @current_user.uid

  unless user_uid == requested_user_id
    status 403
    return { error: 'Forbidden: cannot access other users’ settings' }.to_json
  end

  firestore = Google::Cloud::Firestore.new
  doc_ref = firestore.doc("users/#{user_uid}/settings")
  snapshot = doc_ref.get
  if snapshot.exists?
    snapshot.data.to_json
  else
    status 404
    { error: 'Settings not found' }.to_json
  end
end

Principle 3: Use Firestore queries that enforce ownership

When retrieving lists or performing searches, include the user UID as a query filter rather than relying on client-supplied filters. This prevents IDOR via query manipulation.

# Safe query: filter by owner UID server-side
get '/messages' do
  user_uid = @current_user.uid
  firestore = Google::Cloud::Firestore.new
  messages_ref = firestore.col(collection: 'messages')
                       .where(:recipient_uid, '=', user_uid)
                       .limit(50)
  results = messages_ref.get.map(&:data)
  results.to_json
end

Principle 4: Align Firestore security rules with application checks

Firestore rules should complement Sinatra checks, not replace them. Define rules that require authentication and scope writes to the owner’s path. Use request.auth.uid to enforce ownership at the database level as a defense-in-depth measure.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/profile {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    match /messages/{messageId} {
      allow read: if request.auth != null && request.auth.uid == resource.data.recipient_uid;
      allow write: if request.auth != null && request.auth.uid == request.resource.data.sender_uid;
    }
  }
}

Principle 5: Avoid exposing Firestore internals and validate input

Sanitize and validate all inputs before using them in document paths or queries. Do not concatenate untrusted input into collection or document names. Prefer known, controlled document IDs or slugs mapped server-side to Firestore keys.

# Example: map a friendly slug to a document ID server-side
get '/articles/:slug' do
  slug = params['slug']
  user_uid = @current_user.uid
  # Server-side mapping prevents path traversal or enumeration
  doc_ref = firestore.doc("users/#{user_uid}/articles/#{slug}")
  # ... proceed safely
end