Bola Idor in Rails with Jwt Tokens

Broken Object Level Authorization (BOLA) occurs when an API fails to enforce access controls at the object level, allowing one user to view or modify another user’s resources. In Ruby on Rails applications that use JWT tokens for authentication, this risk emerges from a mismatch between stateless token validation and stateful resource ownership checks.

JWT tokens typically carry a user identifier (e.g., sub or user_id) and are validated using a secret or public key. Once validated, the application may trust the payload and use current_user.id directly in controller actions without confirming that the requested resource belongs to that user. Because JWTs are self-contained and often long-lived compared to session cookies, the window for unsafe direct object references increases if developers skip ownership checks.

Consider a typical Rails controller for profiles:

class ProfilesController < ApplicationController
  before_action :authenticate_user_from_token!

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

  private

  def authenticate_user_from_token!
    token = request.headers['Authorization']&.split(' ')&last
    return unless token

    decoded = JWT.decode(token, Rails.application.secrets.secret_key_base, true, { algorithm: 'HS256' })
    @current_user = User.find(decoded[0]['user_id'])
  rescue JWT::DecodeError
    render json: { error: 'Unauthorized' }, status: :unauthorized
  end
end

In this example, the controller decodes the JWT, finds the user, and then finds the profile by ID. If an attacker knows or guesses another user’s profile ID (e.g., sequential integers or UUIDs), they can access any profile because the controller does not verify that the profile’s user_id matches the authenticated user’s ID. This is a classic BOLA/IDOR scenario: authentication succeeds via JWT, but authorization is missing at the object level.

The problem is compounded when JWTs contain roles or scopes but the application does not re-check those claims against the resource. An attacker who obtains a valid JWT with a privileged scope might exploit missing checks to escalate behavior across object boundaries. Because the scan list includes BOLA/IDOR as one of the 12 parallel checks, middleBrick can surface these authorization gaps when they appear in unauthenticated attack surface testing, even when JWTs are present.

In Rails, resource ownership must be enforced explicitly. Relying solely on JWT payloads for identification without verifying ownership relationships opens a path to unauthorized data access, aligning with the OWASP API Top 10 and relevant compliance mappings that middleBrick reports against.

Remediation centers on ensuring that every data access ties the resource to the authenticated subject derived from the JWT. Do not treat the decoded payload as a sufficient authorization check; always scope queries by the user identifier.

1) Scope queries by user_id:

class ProfilesController < ApplicationController
  before_action :authenticate_user_from_token!

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

  private

  def authenticate_user_from_token!
    token = request.headers['Authorization']&.split(' ')&last
    return unless token

    decoded = JWT.decode(token, Rails.application.secrets.secret_key_base, true, { algorithm: 'HS256' })
    @current_user = User.find_by(id: decoded[0]['user_id'])
    render json: { error: 'Unauthorized' }, status: :unauthorized unless @current_user
  rescue JWT::DecodeError
    render json: { error: 'Unauthorized' }, status: :unauthorized
  end

  def current_user
    @current_user
  end
  helper_method :current_user
end

By calling current_user.profiles.find, Rails ensures the profile must belong to the user identified by the JWT. If no such profile exists, ActiveRecord::RecordNotFound is raised, which you can rescue to return a 404, avoiding information leakage about existence.

2) Use has_many associations and policy scopes:

class User < ApplicationRecord
  has_many :profiles, dependent: :destroy
end

class Profile < ApplicationRecord
  belongs_to :user
end

With this association, current_user.profiles is scoped automatically, and find operates within that scope. For more complex rules, consider using policy scopes or a dedicated authorization library, but the principle remains: never trust params[:id] alone when a JWT identifies the user.

3) Validate claims against the resource when necessary:

def show
  @profile = Profile.find(params[:id])
  unless @profile.user_id == current_user.id
    render json: { error: 'Forbidden' }, status: :forbidden
    return
  end
  render json: @profile
end

This explicit check mirrors what BOLA/IDOR scanners verify: that the subject from the token maps to the object requested. middleBrick’s findings include such patterns so you can prioritize fixes where ownership checks are missing.

4) Shorten JWT lifetime and use refresh tokens cautiously:

# config/initializers/devise.rb or equivalent
config.expire_auth_token_on_timeout = true
# Consider short-lived access tokens with refresh token rotation
# to reduce the impact of a leaked token while maintaining usability.

While this does not fix missing object-level checks, it limits the window an exposed JWT can be abused. Combine this with consistent ownership validation to align with security best practices mapped to standards such as OWASP API Top 10 and compliance frameworks that middleBrick surfaces in reports.