Bola Idor in Rails with Basic Auth

Broken Object Level Authorization (BOLA), commonly referred to as Insecure Direct Object References (IDOR), occurs when an API exposes internal object references (e.g., numeric IDs or UUIDs) without verifying that the requesting user is authorized to access that specific resource. In Ruby on Rails, this often manifests when controller actions like show, update, or destroy scope records by an ID provided in the URL without confirming the record belongs to the requesting user.

When Basic Auth is used without additional authorization checks, the problem becomes more nuanced. Basic Auth typically validates the user once per request (via authenticate_or_request_with_http_basic), establishing identity but not ensuring proper authorization between resources. An authenticated user might be able to iterate through numeric IDs and access other users’ data because Rails does not automatically enforce ownership or tenant boundaries. For example, a route like GET /api/v1/profiles/1 authenticated as Alice could allow Alice to change the ID to 2 and access another user’s profile if the controller does not scope the query to the authenticated user.

Consider a typical Rails controller that loads a record by ID:

class Api::V1::ProfilesController < ApplicationController
  before_action :authenticate_user!

  def show
    @profile = Profile.find(params[:id])
    render json: @profile
  end
end

Even with a before_action that authenticates via HTTP Basic, this action is vulnerable because it does not verify that the found Profile belongs to the authenticated user. An attacker authenticated with valid credentials can enumerate IDs and read or infer sensitive information belonging to other users, which middleBrick’s BOLA checks are designed to detect.

The risk is compounded when controllers expose nested resources without proper scoping:

class Api::V1::UsersController < ApplicationController
  before_action :set_user

  def show
    render json: @user.settings
  end

  private

  def set_user
    @user = User.find(params[:user_id])
  end
end

If user_id is taken directly from the URL and not validated against the current authenticated identity, this becomes another BOLA vector. middleBrick’s scans, including its LLM/AI Security module, look for such patterns by correlating OpenAPI/Swagger specifications with runtime behavior to identify missing authorization checks across endpoints.

In Rails, BOLA with Basic Auth is not just about missing current_user checks; it’s about failing to constrain queries to the authenticated subject across all object-level operations. The framework provides the tools, but without explicit scoping, the vulnerability exists.

To mitigate BOLA when using Basic Auth in Rails, you must explicitly scope every data access to the authenticated subject. This means deriving the permitted object from the authenticated identity rather than trusting user-supplied IDs alone.

1. Authenticate and scope in the controller

Instead of finding a record purely by ID, find it through the association that links it to the authenticated user. This ensures that even if an attacker modifies the ID, they cannot access records that do not belong to the authenticated identity.

class Api::V1::ProfilesController < ApplicationController
  before_action :authenticate_user!

  def show
    @profile = current_user.profile
    render json: @profile
  end
end

In this pattern, current_user is expected to be set by your authentication logic (e.g., via HTTP Basic Auth credentials mapped to a user). The controller no longer accepts an arbitrary :id to look up the profile; it directly accesses the profile associated with the authenticated user.

2. Use strong parameters and avoid ID-based lookup for sensitive actions

For actions that modify data, continue to avoid using user-provided IDs to locate records. If you must accept an ID for nested resources, validate ownership before proceeding:

class Api::V1::PostsController < ApplicationController
  before_action :authenticate_user!
  before_action :set_post, only: %i[show update destroy]

  def show
    render json: @post
  end

  private

  def set_post
    @post = Post.where(id: params[:id], user: current_user).take!
  rescue ActiveRecord::RecordNotFound
    render json: { error: 'Not found' }, status: :not_found
  end
end

This query ensures that the post both exists and belongs to the authenticated user. If the condition fails, take! raises an exception, which you can handle to return a 404 instead of a 403, avoiding information leakage about existence.

3. Example Basic Auth setup in Rails

Here is a complete example of how you might implement Basic Auth and enforce scoping in a Rails controller:

class ApplicationController < ActionController::API
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_basic do |username, password|
      user = User.find_by(username: username)
      if user&;authenticate(password)
        @current_user = user
      end
    end
  end

  def current_user
    @current_user
  end
  helper_method :current_user
end

With this setup, every controller that inherits from ApplicationController will have a current_user method available. Controllers should then use current_user to build scoped queries, as shown earlier, rather than relying on raw IDs from the request.

middleBrick’s scans can help identify endpoints where authentication is present but scoping is missing, highlighting the exact locations where BOLA risks exist in your Rails API.