Api Rate Abuse in Phoenix with Firestore

Rate abuse in a Phoenix API that uses Google Firestore as a backend can manifest when client-side request patterns are not properly constrained and server-side protections are absent. Without effective rate limiting, an attacker can send a high volume of requests to endpoints that interact with Firestore, leading to excessive reads, writes, or queries that degrade performance, increase costs, and expose sensitive data through timing or error differences.

Phoenix, being an Elixir-based framework, relies on plug pipelines and connection handling. If rate limiting is not enforced at the pipeline level (for example, using PlugAttack or a custom rate plug), repeated requests to an endpoint like /api/users/:id that performs a Firestore document read can be issued rapidly. Because Firestore operations are remote calls with variable latency, attackers can use this to perform timing-based probing or to trigger error conditions that reveal the presence of specific documents or indexes.

Firestore-specific risks arise when endpoints expose document IDs or query patterns that depend on client-supplied identifiers. For example, an endpoint that accepts an ID parameter and retrieves a document without validating ownership or context can be targeted with many IDs to enumerate valid records. In a Phoenix controller, a naive implementation might look like this:

defmodule MyAppWeb.UserController do
  use MyAppWeb, :controller

  def show(conn, %{"id" => id}) do
    case Firestore.get_document("users", id) do
      {:ok, data} -> json(conn, data)
      {:error, _} -> send_resp(conn, 404, "Not found")
    end
  end
end

Without per-identity rate limiting, an attacker can call this endpoint with many different IDs or the same ID in rapid succession. Firestore will process each request, and the cumulative read operations can contribute to higher costs and noisy metrics. Additionally, if responses differ slightly in timing or error messages between missing documents and unauthorized access, an attacker can infer whether a given document exists, aiding in enumeration or reconnaissance.

The interaction between Phoenix plug pipelines and Firestore client retries can amplify abuse. If the Firestore client is configured with aggressive retry policies and the Phoenix endpoint does not enforce request-rate controls, a single malicious client can trigger many retries and backend calls, effectively multiplying the load. This can lead to throttling errors from Firestore or saturation of connection pools on the backend, which may affect legitimate traffic.

A concrete abuse scenario: an unauthenticated endpoint that lists recent public posts queries Firestore with a non-indexed or broad query and does not enforce rate limits. An attacker can script rapid requests with crafted query parameters to force repeated scans or to probe for data leakage through error responses. Because the scan is unauthenticated and the endpoint relies on Firestore query patterns, this maps to the BFLA/Privilege Escalation and Data Exposure checks in middleBrick’s 12 security checks.

To detect such issues, middleBrick runs active tests including rate-limiting checks and unsafe consumption analysis, correlating runtime behavior with OpenAPI/Swagger specs (including $ref resolution) to highlight where controls are missing. The scanner does not fix the configuration but provides prioritized findings with remediation guidance, helping teams understand how to constrain request rates and isolate Firestore interactions behind proper authorization and validation.

Remediation focuses on applying rate limiting close to the Phoenix pipeline and ensuring Firestore interactions enforce strict ownership and query constraints. Rate limiting should be implemented as a plug that tracks identifiers (such as IP or API key) and enforces a token bucket or fixed window algorithm before requests reach controller logic.

Example plug-based rate limiting using a simple in-memory ETS table for demonstration (prefer a distributed store like Redis in production):

defmodule MyAppWeb.RateLimitPlug do
  @limit 30          # requests
  @window 60_000     # milliseconds

  def init(opts), do: opts

  def call(conn, _opts) do
    key = conn.remote_ip |> :inet.ntoa() |> to_string()
    now = System.system_time(:millisecond)
    bucket_key = {key, div(now, @window)}

    count = :ets.lookup_element(:rate_table, bucket_key, 2, 0)
    if count >= @limit do
      conn
      |> Plug.Conn.send_resp(429, "Too Many Requests")
      |> Plug.Conn.halt()
    else
      :ets.insert(:rate_table, {bucket_key, count + 1})
      conn
    end
  end
end

Plug this into your pipeline before the Firestore-dependent routes:

pipeline :api do
  plug :accepts, ["json"]
  plug MyAppWeb.RateLimitPlug
  plug :fetch_session
  # other plugs...
end

On the Firestore side, always validate ownership and scope before reading or writing. Avoid using raw client IDs to construct document paths. Instead, map authenticated user identities to Firestore document references on the server:

defmodule MyAppWeb.UserController do
  use MyAppWeb, :controller

  def show(conn, %{"id" => id}) do
    with {:ok, user} <- Accounts.get_user_by_id(id),
         true <- Accounts.user_owns?(conn.assigns.current_user, user) do
      case Firestore.get_document("users", user.external_id) do
        {:ok, data} -> json(conn, data)
        {:error, _} -> send_resp(conn, 404, "Not found")
      end
    else
      _ -> send_resp(conn, 403, "Forbidden")
    end
  end
end

To reduce Firestore read amplification, cache or batch requests where appropriate, and ensure queries are indexed and scoped tightly. Avoid returning large document sets to unauthenticated endpoints; require authentication and apply strict filters. Combine these practices with middleBrick’s continuous monitoring and GitHub Action integration (PR gates) to ensure new changes do not introduce regressions in rate control or data exposure risks.