Broken Access Control in Grape (Ruby)

Broken Access Control occurs when API endpoints fail to enforce proper authorization checks, allowing one user to act on another user's resources. Using Grape with Ruby can inadvertently expose this risk when developers define scopes and helpers but omit per-route authorization, rely on ambiguous policy evaluation, or mismanage current user scoping. Because Grape encourages concise, resource-focused routes, it is easy to forget to gate actions such as DELETE, PUT, or PATCH behind a check that the requesting subject has explicit rights to that specific record.

In Grape, developers often mount helpers like current_user or current_account, which are typically populated from token or session data. If routes assume that authenticated identity is sufficient for authorization, any API consumer who obtains or guesses another entity's identifier can manipulate those endpoints. For example, an endpoint like /api/v1/invoices/:id that loads an invoice by ID without confirming that the invoice belongs to the caller's account creates a classic BOLA/IDOR pattern. Grape does not automatically enforce ownership; it is the developer's responsibility to ensure each endpoint validates subject-to-object permissions.

Additionally, Grape allows nested routes and parameter-based scoping that can leak information if not handled carefully. A route that exposes internal IDs without considering horizontal privilege boundaries can let a user traverse associations unintentionally. For instance, if an admin-only route is only superficially guarded by a role check but does not validate whether the admin belongs to the same organization, an attacker with a low-privilege account might escalate by altering the organization context in the request. This is particularly relevant when using before blocks in Grape that set variables like @current_account based on subdomain or header values without cross-checking the authenticated actor's affiliation.

Another subtle source of risk is the interaction between Grape validations and authorization logic. Strong parameter validation can give a false sense of security; even when parameters are sanitized, the endpoint might still serve data to the wrong user if the query scope does not include a tenant or user filter. Consider a Grape resource that defines params do requires :status, type: String end and then queries Invoice.where(status: params[:status]) without scoping to the current user. An authenticated user could enumerate statuses and retrieve invoices that do not belong to them, resulting in data exposure that violates both confidentiality and integrity expectations.

These patterns map directly to the OWASP API Top 10 category for Broken Access Control, which remains a prevalent class of API risk. Because Grape is lightweight and opinionated, developers must deliberately embed authorization checks at the resource level, validate ownership with per-request scoping, and audit role and scope usage to ensure that what is authenticated is also properly authorized.

To mitigate Broken Access Control in Grape with Ruby, apply strict scoping and explicit checks in route handlers and before blocks. Always resolve the subject from the request context and intersect data queries with the subject identifier, rather than relying on client-supplied IDs alone. Below are concrete, idiomatic patterns that reduce risk while keeping Grape's expressive style intact.

1. Scope data access to the authenticated subject

Ensure that every query includes a tenant or user scope. Instead of loading a record by ID directly, first verify ownership or role-based access.

class InvoiceResource < Grape::API
  helpers do
    def current_user
      @current_user ||= User.find_by(auth_token: headers['Authorization'])
    end
  end

  resource :invoices do
    desc 'Show invoice belonging to the current user'
    params do
      requires :id, type: Integer, desc: 'Invoice ID'
    end
    get ':id' do
      invoice = current_user.invoices.find(params[:id])
      present invoice, with: Entities::InvoiceEntity
    rescue ActiveRecord::RecordNotFound
      error!('Not found', 404)
    end
  end
end

2. Use policy objects for centralized authorization

Define policy classes that encapsulate permission logic. Call them explicitly in routes to keep authorization decisions visible and testable.

class InvoicePolicy
  attr_reader :user, :invoice

  def initialize(user, invoice)
    @user = user
    @invoice = invoice
  end

  def show?
    invoice.user_id == user.id || user.admin?
  end
end

class InvoiceResource < Grape::API
  helpers do
    def authorize_invoice!(invoice)
      raise Grape::Exceptions::Forbidden unless InvoicePolicy.new(current_user, invoice).show?
    end
  end

  resource :invoices do
    desc 'Show invoice with explicit authorization'
    params do
      requires :id, type: Integer, desc: 'Invoice ID'
    end
    get ':id' do
      invoice = Invoice.find(params[:id])
      authorize_invoice!(invoice)
      present invoice, with: Entities::InvoiceEntity
    end
  end
end

3. Validate scoping in before blocks for nested resources

When routes are nested, validate that the parent context matches the actor's scope before proceeding.

class ProjectResource < Grape::API
  before do
    @project = Project.includes(:members).find_by(id: params[:project_id])
    error!('Forbidden', 403) unless @project && @project.members.exists?(current_user.id)
  end

  resource :tasks do
    desc 'List tasks for a project the user can access'
    get do
      present @project.tasks, with: Entities::TaskEntity
    end
  end
end

4. Avoid relying solely on role checks without instance-level validation

Roles alone are insufficient when actions target specific instances. Combine role checks with ownership or explicit allow-lists.

class AdminResource < Grape::API
  helpers do
    def current_admin
      @current_admin ||= Admin.find_by(token: headers['X-Admin-Token'])
    end
  end

  resource :reports do
    desc 'Retrieve a report scoped to the admin organization'
    params do
      requires :report_id, type: Integer, desc: 'Report ID'
    end
    get ':report_id' do
      report = Report.where(organization_id: current_admin.organization_id).find(params[:report_id])
      present report, with: Entities::ReportEntity
    end
  end
end

By embedding these patterns, developers using Grape and Ruby reduce the attack surface associated with Broken Access Control, ensuring that authentication is coupled with precise, query-level authorization.