Injection Flaws in Rails with Firestore

Injection flaws in a Ruby on Rails application that uses Google Cloud Firestore typically arise when untrusted input is used to dynamically construct queries, collection or document identifiers, or security rules. Unlike SQL, Firestore does not have a traditional query language with parameterized prepared statements; instead, queries are built programmatically. If Rails code interpolates user-controlled values directly into these query-building calls or document paths, attackers can manipulate the structure of the read or write operations.

For example, consider a route like GET /users/:user_id/posts. If the controller resolves the user reference by string concatenation to form a document path such as "users/#{params[:user_id]}/posts", an attacker can supply path traversal sequences or crafted values to reach documents outside their intended scope. This can lead to Insecure Direct Object Reference (IDOR) or access to other tenants’ data when combined with missing ownership checks.

Firestore security rules can also be exposed through injection-like behavior when rule logic is overly permissive or when dynamic key access is used without strict validation. If rules include map keys derived from unvalidated input, an attacker may probe for writable fields or bypass intended constraints. Additionally, Rails code that deserializes incoming JSON into Firestore document updates without a strict whitelist of permitted fields can allow mass assignment or injection of unexpected metadata that changes behavior.

The scan dimensions relevant here include Authentication (are Firestore credentials exposed via misconfigured initializers?), BOLA/IDOR (can a user read or modify another user’s documents via path manipulation?), and Input Validation (are incoming parameters validated and sanitized before being used in Firestore paths or rule evaluation?). Because middleBrick tests the unauthenticated attack surface, it can detect endpoints where Firestore rules permit unintended read or write access based on manipulated identifiers, and it flags missing input validation that would allow injection-style manipulation of queries or paths.

Another important dimension is Unsafe Consumption and Property Authorization. If Rails passes raw user input to Firestore field names or uses dynamic model attributes without verifying property-level permissions, an attacker may inject fields that change data semantics or exfiltrate sensitive properties. Data Exposure and Encryption checks will highlight cases where sensitive data is written without appropriate rule constraints or encryption at rest assumptions are incorrectly relied upon.

Defensive coding patterns and explicit validation are essential when using Firestore in Rails. Always treat user input as untrusted and avoid building document paths or queries by string interpolation. Use whitelists for permitted fields and validate IDs against a known format before using them in paths.

Safe document path construction

Instead of concatenating IDs into paths, use Firestore’s helpers and validate the ID format. For example, use a regular expression to ensure a user ID matches an expected pattern, then build the document reference safely:

# app/services/firestore_user_posts.rb
class FirestoreUserPosts
  def initialize(user_id)
    raise ArgumentError, 'Invalid user_id' unless user_id.match?(/^\w{1,30}$/)

    @client = Google::Cloud::Firestore.new
    @user_ref = @client.collection('users').doc(user_id)
  end

  def recent_posts(limit = 10)
    @user_ref.collection('posts')
            .order(created_at: :desc)
            .limit(limit)
            .get
  end
end

Whitelisted updates to prevent mass assignment

When applying user-provided parameters to update a Firestore document, explicitly permit only known fields rather than passing the raw params hash:

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  ALLOWED_POST_FIELDS = %w[title content published].freeze

  def update
    user = current_user
    post_ref = user.firestore_ref.collection('posts').doc(params[:id])
    raw = post_params

    filtered = raw.select { |k| ALLOWED_POST_FIELDS.include?(k) }
    post_ref.update(filtered)

    head :no_content
  end

  private

  def post_params
    params.require(:post).permit(ALLOWED_POST_FIELDS)
  end
end

Secure query construction

Avoid dynamic field names in queries. If you must filter by a user-supplied field, map it through a strict allowlist:

# app/queries/post_search.rb
class PostSearch
  VALID_SORT_FIELDS = %w[created_at title].freeze

  def self.call(collection_name, sort_by, direction)
    raise ArgumentError, 'Invalid sort field' unless VALID_SORT_FIELDS.include?(sort_by)
    raise ArgumentError, 'Invalid direction' unless %w[asc desc].include?(direction)

    client = Google::Cloud::Firestore.new
    collection = client.collection(collection_name)
    collection.order(sort_by, direction: direction).limit(20).get
  end
end

Rule design guidance

When authoring Firestore security rules, prefer exact key matches and avoid dynamic key access based on request data. Validate that request resource IDs conform to expected formats and enforce ownership checks explicitly. Do not rely on rules alone to compensate for missing Rails-side validation; use both layers to reduce risk.

Leveraging middleBrick checks

Use the middleBrick CLI to validate your endpoints and rule configurations: middlebrick scan <url>. The scan will surface findings related to IDOR, Input Validation, and Unsafe Consumption specific to Firestore integrations. For continuous assurance, the Pro plan provides scheduled scans and GitHub Action integration to fail builds when risk scores exceed your defined thresholds, helping you maintain a secure posture without manual checks.