Injection Flaws in Sinatra with Firestore

Injection flaws occur when untrusted data is interpreted as part of a command or query. In a Sinatra application that uses Google Cloud Firestore, risk arises when user input is directly embedded into Firestore queries, key paths, or document IDs without validation or escaping. Firestore’s query language is not SQL, but injection risks remain when constructing queries dynamically, especially using string concatenation or interpolation to build collection or document references, filter values, or field paths.

Because Sinatra is a lightweight Ruby DSL for HTTP routing, developers may write code like params[:id] directly into Firestore get or query calls. If input is not strictly validated, an attacker can supply crafted values that change query semantics or traverse the document hierarchy. For example, a document ID containing path traversal sequences or unexpected characters can lead to reading or writing unintended data. In some configurations, insufficient input validation can enable data exfiltration across logical boundaries by manipulating key values that reference other users’ resources.

Firestore’s client libraries typically use parameterized queries for collection groups and simple lookups, but developers sometimes bypass these patterns by constructing queries with Ruby string interpolation. This increases the likelihood of logic flaws, such as bypassing intended access boundaries or leaking data through overly broad queries. The risk is compounded when combined with weak authentication or missing authorization checks, allowing an attacker to reference collections or documents they should not access.

In the context of middleBrick’s checks, this behavior may be flagged under BOLA/IDOR, Input Validation, and Property Authorization. The scanner tests whether query construction is deterministic for a given unauthenticated request and whether values like collection names or document IDs can be controlled to reference sensitive data. Although Firestore enforces its own backend permissions, application-layer query construction mistakes can still expose more data than intended or allow enumeration of resources.

An example of a risky pattern is using user input directly in a Firestore collection reference without normalization or allowlisting:

get '/items/:collection' do
  collection_name = params[:collection]
  docs = firestore_client.collection(collection_name).get
  # potentially unsafe: collection_name is not validated
  # ... render results
end

If collection_name is user-supplied, an attacker could probe collections that should be restricted. MiddleBrick’s tests for Unsafe Consumption and Inventory Management can detect such patterns by analyzing the API surface and runtime behavior to identify endpoints where structure and permissions are not tightly bound.

Remediation focuses on strict input validation, allowlisting, and using Firestore’s client features as intended. Avoid constructing collection or document references from raw user input. Instead, map user-friendly identifiers to predefined, safe references.

Use allowlists for collection names and document IDs. Do not concatenate or interpolate user input into paths. Prefer parameterized access and explicit mapping.

Safe example with allowlisted collections:

ALLOWED_COLLECTIONS = %w[products orders users]

get '/items/:collection' do
  collection_name = params[:collection]
  unless ALLOWED_COLLECTIONS.include?(collection_name)
    halt 400, { error: 'invalid collection' }.to_json
  end
  firestore_client.collection(collection_name).get.to_a
end

For document lookups, use numeric or UUID identifiers that your server maps to Firestore document IDs, rather than passing identifiers directly:
get '/items/:item_id' do
  item_id = params[:item_id]
  # Validate format before use
  halt 400, { error: 'invalid item id' }.to_json unless item_id =~ /\A[a-f0-9\-]{36}\z/ # UUID example
  doc_ref = firestore_client.doc("users/#{current_user_id}/items/#{item_id}")
  doc = doc_ref.get
  halt 404, { error: 'not found' }.to_json if doc.nil?
  doc.to_h
end

When querying, use Firestore’s built-in query methods with explicit field values instead of dynamic field names. If dynamic field access is required, validate field names against an allowlist:
ALLOWED_SORT_FIELDS = %w[name created_at status]

get '/search' do
  field = params[:sort_by]
  order = params[:order] || 'asc'
  halt 400, { error: 'invalid sort field' }.to_json unless ALLOWED_SORT_FIELDS.include?(field)
  query = firestore_client.collection('items').order_by(field, direction: order.to_sym)
  query.get.to_a
end

For Firestore security, enforce server-side authorization checks for each read or write. Do not rely solely on Firestore rules for multi-tenant isolation; validate that the requesting user has access to the specific document or subcollection. This prevents BOLA/IDOR-type issues where an attacker iterates through identifiers to access other users’ data.
In production, combine these practices with middleware that normalizes and validates request parameters early. The middleBrick CLI can be run against your Sinatra API to surface risky patterns such as unchecked query construction or endpoints that accept user-controlled collection or document identifiers. For teams using continuous integration, the GitHub Action can enforce a minimum security score and fail builds when new issues are introduced.