Injection Flaws in Grape with Mongodb

Grape is a REST-like API micro-framework for Ruby, commonly used to build JSON APIs. When building endpoints that accept client input and pass it to a MongoDB backend, improper handling of that input can lead to injection flaws. Injection occurs when untrusted data is interpreted as part of a command or query without proper validation, sanitization, or parameterization.

In the context of a Grape API using Mongoid (the ODM for MongoDB), developers often construct queries by directly interpolating params into Mongoid criteria or the underlying MongoDB query hash. For example, using where({ :name => params[:name] }) may appear safe, but if the query is built dynamically with Ruby string interpolation or if the input is used to construct JSON query documents in an uncontrolled way, attackers can inject operators that alter query logic. A classic pattern that introduces risk is building a filter like { "$where" => "this.code == #{params[:code]}" }, which evaluates JavaScript on the server side and can lead to arbitrary code execution on the database.

Beyond direct query injection, injection flaws in Grape with MongoDB can manifest through several vectors that the 12 security checks of middleBrick evaluate in parallel. These include Input Validation, which examines whether incoming data is constrained and sanitized; Property Authorization, which checks whether user-supplied property names can modify fields they should not; and Unsafe Consumption, which inspects whether data is deserialized or interpreted without strict schema enforcement. If a Grape endpoint accepts a JSON body that is forwarded verbatim into a MongoDB aggregation pipeline using $where, $eval, or other JavaScript-evaluating stages, an attacker may supply payloads that execute unintended logic. Similarly, if field names in a sort or projection are taken directly from user input without an allowlist, this can lead to sensitive data exposure or privilege escalation via BOLA/IDOR when combined with missing ownership checks.

middleBrick tests these scenarios by running the API unauthenticated and observing behavior when injection-like payloads are supplied. It checks whether operators such as $ne, $gt, or $where can be coerced into the query structure through nested JSON or URL-encoded forms. The scanner also inspects the OpenAPI specification, if available, to determine whether parameter schemas overly use type: string with no pattern restrictions or type: object with no validation, which can facilitate injection attempts. Because MongoDB’s query language supports nested documents and operator chains, an API that does not rigorously constrain keys and values can allow an attacker to bypass authentication filters or read arbitrary documents, leading to Data Exposure findings.

When reviewing scan results from middleBrick, teams often see findings tied to the broader categories of Input Validation and Property Authorization. An insecure endpoint might accept a query parameter like ?filter={"email": {"$ne": ""}} and pass it directly to a Mongoid model, effectively bypassing intended filters. This illustrates how injection flaws in Grape with MongoDB are not solely about code execution but also about logic manipulation and unauthorized data access. Remediation requires strict schema validation, operator allowlisting, and avoiding dynamic JavaScript evaluation on the database side.

To secure Grape APIs that interact with MongoDB, apply strict input validation and avoid constructing queries via string interpolation or dynamic JavaScript evaluation. Always use parameterized queries and schema-level constraints. Below are concrete, safe patterns for common scenarios.

Safe query construction with allowlisted fields

Instead of passing user input directly into a query, define an allowlist of permitted fields and map validated values to known query keys. This prevents attackers from injecting operators through unexpected parameter names.

# config/initializers/mongoid.rb (ensure safe settings)
Mongoid.configure do |config|
  config.connect_timeout = 15
  config.socket_timeout = 15
end

# app/api/v1/profiles.rb
class API::V1::Profiles < Grape::API
  format :json

  helpers do
    def permitted_profile_params
      declared_params = params.permit(:user_id, :status, :role)
      # Only allow known fields; ignore anything unexpected
      { user_id: declared_params[:user_id], status: declared_params[:status] }
    end
  end

  get '/profiles' do
    filters = permitted_profile_params
    # Safe: filters contain only expected keys with scalar values
    Profile.where(filters).to_a
  end
end

Avoiding $where and JavaScript evaluation

Never construct queries that include $where or pass raw strings to be evaluated. Use Mongoid’s standard query interface which translates to safe MongoDB queries.

# Unsafe — do not use
# Profile.where("{ $where: 'this.status == \"active\" && this.count > #{params[:min_count]}' }")

# Safe — parameterized query without JavaScript
class API::V1::Reports < Grape::API
  get '/reports' do
    min_count = params[:min_count].to_i
    # Use standard operators with bound values
    Report.where(:status.ne => nil, :count.gt => min_count).to_a
  end
end

Input validation with schema constraints

Use strong parameters and, where applicable, a validation layer such as Dry::Validation or simple type checks to ensure incoming data matches expected types and formats.

# app/api/base.rb
class Base < Grape::API
  before do
    header['Content-Type'] == 'application/json' || true
  end
end

# app/api/v1/users.rb
class API::V1::Users < Base
  params do
    requires :email, type: String, format: EmailValidator
    optional :role, type: String, values: %w[admin user guest]
  end
  post '/users' do
    User.create!(declared(params))
  end
end

Projection and sort allowlisting

When using user input to influence projections or sorts, validate against a fixed set of allowed keys to prevent data exposure or BOLA manipulation.

ALLOWED_SORT_FIELDS = %w[name created_at status]

params do
  optional :sort, type: String, values: ALLOWED_SORT_FIELDS
end
get '/items' do
  sort_field = params[:sort] || 'created_at'
  direction = params[:dir] == 'desc' ? -1 : 1
  Item.order(sort_field.to_sym => direction).to_a
end