Excessive Data Exposure in Grape with Mongodb

Excessive Data Exposure occurs when an API returns more data than necessary, often including sensitive fields that should remain internal or be withheld based on caller permissions. Using Grape with MongoDB can unintentionally amplify this risk when endpoint definitions do not explicitly limit returned fields and when MongoDB queries project full documents by default.

In Grape, a common pattern is to map incoming requests directly to MongoDB queries without constraining the projection. For example, consider an endpoint designed to return user profile information:

class UserResource < Grape::Entity
  expose :id
  expose :name
  expose :email
end

class UsersEndpoint < Grape::API
  resource :users do
    get ':id' do
      user = Mongo::Client.new(['mongodb://localhost:27017'], database: 'app_db')[:users].find({ _id: BSON::ObjectId(params[:id]) }).first
      present user, with: UserResource
    end
  end
end

If the MongoDB query does not specify a projection, the document returned from the collection may contain sensitive fields such as password_hash, auth_tokens, or internal metadata. Even if the Grape entity only exposes a subset of fields, the underlying data has already been retrieved and processed, increasing the risk of accidental leakage through logs, error messages, or future code changes.

This combination is particularly problematic when developers rely on implicit behavior: MongoDB returns the full document unless explicitly instructed to exclude fields, and Grape may inadvertently encourage broad data exposure when entities are reused across endpoints without strict field scoping. Attackers who gain access to API responses might obtain credentials, personally identifiable information (PII), or operational details that facilitate further attacks such as privilege escalation or social engineering.

Additionally, if query parameters are used to filter or sort without proper validation, attackers might manipulate the request to retrieve records belonging to other users (a related BOLA/IDOR concern) while also receiving excessive fields. MiddleBrick scans detect these patterns by correlating OpenAPI specifications with runtime behavior, highlighting endpoints where projections are missing and where returned data extends beyond declared entity contracts.

To prevent Excessive Data Exposure when using Grape and MongoDB, explicitly define projection for every query to include only necessary fields. This ensures sensitive data never leaves the database layer, reducing both risk and reliance on later filtering.

Below is a secure version of the previous example, using a targeted projection and a constrained Grape entity:

class UserResource < Grape::Entity
  expose :id
  expose :name
  expose :email
  # Do not expose password_hash, auth_tokens, or internal flags
end

class UsersEndpoint < Grape::API
  resource :users do
    get ':id' do
      client = Mongo::Client.new(['mongodb://localhost:27017'], database: 'app_db')
      user = client[:users].find(
        { _id: BSON::ObjectId(params[:id]) },
        projection: { name: 1, email: 1, id: '$_id', _id: 0 }
      ).first

      error!('User not found', 404) unless user
      present user, with: UserResource
    end
  end
end

The projection parameter ensures only name, email, and the mapped id are returned, excluding password_hash and other sensitive fields at the source. Using _id: 0 prevents the raw MongoDB _id from being included in the response, while mapping id: '$_id' allows controlled exposure of the identifier through the entity.

For endpoints that support filtering or listing, apply the same principle across result sets:

class UsersIndexEndpoint < Grape::API
  resource :users do
    get do
      client = Mongo::Client.new(['mongodb://localhost:27017'], database: 'app_db')
      users = client[:users].find({}, projection: { name: 1, email: 1, id: '$_id', _id: 0 }).to_a
      present users, with: UserResource
    end
  end
end

In addition to projections, validate and sanitize query parameters to prevent injection or unintended data access. Avoid constructing queries from raw user input without constraints, and prefer whitelisted filters over dynamic field selection. MiddleBrick’s OpenAPI and runtime analysis can highlight endpoints missing projections or returning unexpected fields, supporting compliance with OWASP API Top 10 and related standards.