Bola Idor in Grape with Basic Auth

Broken Object Level Authorization (BOLA) occurs when an API fails to enforce authorization checks on individual resources, allowing one user to act on another user's objects. In Grape, a Ruby API framework, this commonly arises when routes rely on identifiers (e.g., :id) without confirming that the authenticated subject owns or is permitted to access that object. When Basic Auth is used, the server validates credentials on each request and makes a user identity available, but if the developer neglects to couple authentication with per-object authorization, BOLA is exposed.

Consider a Grape API where accounts and their nested profiles are modeled as resources. A route like /accounts/:account_id/profile might load the profile by params[:account_id] and return it directly after validating Basic Auth credentials. If the authorization step only checks that a user is logged in (via env['warden'] or a custom header check) and does not verify that the authenticated user’s account matches account_id, the endpoint becomes vulnerable. An attacker who can obtain or guess another valid account identifier can enumerate IDs and read or manipulate profiles they should not access.

Basic Auth introduces a subtle factor: credentials are sent on every request, which can lead developers to assume identity is sufficient for authorization. However, identity (who you are) is not the same as authorization (what you are allowed to do). In Grape, this manifests as missing ownership checks on nested resources, especially when using path parameters that directly reference account or tenant identifiers. For example, a route that maps params[:account_id] to an Account model without scoping by the authenticated user’s account enables horizontal BOLA across accounts. Vertical BOLA can also occur if an endpoint intended for administrators omits role checks and relies only on Basic Auth, allowing lower-privilege users to access admin-only routes simply by knowing the URL.

The interplay becomes risky when session management or caching layers assume that Basic Auth guarantees proper scoping. An API consumer might cache responses keyed by URL, inadvertently exposing one user’s data to another if the server does not enforce per-request authorization. Because Grape allows flexible route definitions, developers must explicitly bind the authenticated identity to the resource being accessed. Without this binding, the API reports a 200 OK for valid credentials but returns data belonging to a different object, which middleBrick flags as a BOLA finding with high severity under the Authorization and BOLA/IDOR checks.

To fix BOLA in Grape when using Basic Auth, always derive the resource ownership or tenant scope from the authenticated identity, not solely from the URL parameter. Use a helper to load the current account based on credentials, then scope all data access through that account. Below is a minimal, secure pattern that ties authentication to authorization.

# app/api/base.rb
class BaseAPI < Grape::API
  format :json
  helpers do
    def current_account
      @current_account ||= begin
        auth = request.env['HTTP_AUTHORIZATION']
        if auth&.start_with?('Basic ')
          encoded = auth.split(' ', 2).last
          decoded = Base64.strict_decode64(encoded).to_s
          username, _password = decoded.split(':', 2)
          Account.find_by(username: username)
        end
      end
    end

    def require_current_account!
      error!({ error: 'Unauthorized' }, 401) unless current_account
    end
  end

  before { require_current_account! }
end

With this helper, each endpoint should scope resources to current_account rather than trusting params[:account_id] alone. For nested routes, verify that the nested resource belongs to the authenticated account:

# app/api/v1/profiles.rb
class ProfilesAPI < BaseAPI
  desc 'Get profile for the authenticated account',
       failure_codes: [401, 403, 404]
  params do
    requires :account_id, type: Integer, desc: 'Account identifier'
  end
  get '/accounts/:account_id/profile' do
    account = current_account
    # Enforce ownership: the requested account_id must match the authenticated account
    error!({ error: 'Forbidden' }, 403) unless account.id == params[:account_id].to_i

    profile = account.profile
    error!({ error: 'Not found' }, 404) unless profile
    profile
  end
end

For endpoints that act on other account-related resources, apply the same scoping pattern. If your domain uses multi-tenancy where accounts own projects, ensure queries filter by account_id derived from credentials:

# app/api/v1/projects.rb
class ProjectsAPI < BaseAPI
  params do
    requires :account_id, type: Integer, desc: 'Account identifier'
    requires :project_id, type: Integer, desc: 'Project identifier'
  end
  get '/accounts/:account_id/projects/:project_id' do
    account = current_account
    error!({ error: 'Forbidden' }, 403) unless account.id == params[:account_id].to_i

    project = Project.where(account_id: account.id, id: params[:project_id]).first
    error!({ error: 'Not found' }, 404) unless project
    project
  end
end

Additionally, avoid exposing raw IDs in URLs when feasible; consider using opaque identifiers or UUIDs to reduce predictability. Always validate and sanitize input, and ensure that any caching respects the authenticated context. These steps align with the Authorization and BOLA/IDOR checks that middleBrick evaluates, helping you achieve a stronger security posture without relying on the presence of a WAF or automated blocking.