Api Key Exposure in Grape with Firestore

When a Grape API exposes Firestore operations without enforcing strict access controls, API keys can be inadvertently exposed through verbose error messages or misconfigured endpoints. Firestore security rules that are too permissive may allow unauthenticated read or write access to collections that should be restricted. If a Grape endpoint directly proxies Firestore credentials or embeds them in client-facing payloads, those keys can be harvested by an attacker. Common patterns include passing service account keys from server-side logic to the client or logging sensitive configuration in responses that are returned during failed validation.

During a middleBrick scan, the Authentication check flags endpoints that return tokens or secrets, while the Property Authorization check detects rules that allow public access to sensitive documents. The Input Validation check identifies cases where user input is used to construct Firestore document paths without sanitization, enabling BOLA/IDOR scenarios that expose internal data structures. For example, an endpoint like /users/:uid/profile that directly maps :uid to a Firestore document path can be manipulated to access other users’ data if ownership is not verified server-side.

Another vector involves Firestore rules that rely on request.auth != null but do not validate the scope of permissions. If an API key with elevated privileges is embedded in client-side code or returned in debug endpoints, middleBrick’s LLM/AI Security checks can detect system prompt leakage or exposed keys in model outputs. The Data Exposure check further identifies whether responses include sensitive fields such as apiKey or serviceAccount in JSON payloads. Combined with Rate Limiting misconfigurations, these issues allow attackers to brute-force keys or exhaust quotas while remaining undetected.

Real-world examples include endpoints that return full Firestore document snapshots without redaction. A vulnerable route might look like this in Grape:

class Api < Grape::API
  namespace :v1 do
    get '/documents/:doc_id' do
      doc = Firestore.get("projects/my-project/databases/(default)/documents/data/#{params['doc_id']}")
      doc.data # Danger: exposes internal structure and potentially sensitive keys
    end
  end
end

If Firestore rules permit read access based only on authentication without validating document ownership, and the response is not filtered, an API key or internal metadata may be returned. middleBrick’s inventory and unsafe consumption checks help identify such endpoints by correlating spec definitions with runtime behavior, ensuring that sensitive fields are never leaked in unauthenticated responses.

Remediation centers on enforcing strict ownership checks, filtering sensitive fields, and avoiding direct exposure of Firestore internals. Always validate that the requesting user is the owner of the resource before querying Firestore. Use server-side field selection to return only necessary data, and never pass API keys or service account tokens to the client.

Secure implementation example in Grape:

class Api < Grape::API
  helpers do
    def current_user
      # Assume authentication middleware sets current_user
      @current_user ||= User.find_by(id: env['current_user_id'])
    end

    def firestore_client
      @firestore_client ||= Firestore.new
    end
  end

  namespace :v1 do
    get '/documents/:doc_id' do
      doc_id = params['doc_id']
      user_id = current_user.id

      # Enforce ownership: ensure the document belongs to the current user
      doc_ref = firestore_client.doc("users/#{user_id}/data/#{doc_id}")
      doc = doc_ref.get

      not_found! unless doc.exists?

      # Explicitly filter sensitive fields before returning
      safe_data = doc.data.except('apiKey', 'serviceAccount', 'internalMetadata')
      { id: doc.id, data: safe_data }
    rescue Google::Cloud::NotFoundError
      not_found!
    end
  end
end

On the Firestore side, security rules should validate ownership and limit read/write scope. Avoid wildcard permissions and use request.auth.uid to enforce user-level isolation:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/data/{document=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Additionally, configure logging and monitoring on the server side to detect unusual access patterns. middleBrick’s continuous monitoring (available in Pro and Enterprise plans) can alert you when endpoints return unexpected data structures or when unauthenticated scans detect relaxed rules. For CI/CD integration, use the GitHub Action to fail builds if scans detect exposed keys or missing ownership checks.

Finally, ensure that any Firestore client initialization on the server does not log or serialize credentials. Use environment variables securely and rotate keys regularly. The MCP Server can help developers scan APIs directly from the IDE, catching these issues before code reaches production.