Bola Idor in Grape with Hmac Signatures

Broken Object Level Authorization (BOLA) is an API security risk where an attacker can access or modify objects they should not have access to. When an API built with the Ruby Grape framework uses HMAC Signatures for request authentication but does not enforce object ownership checks, the combination can expose BOLA despite the presence of signature validation.

HMAC Signatures typically protect integrity and origin by having the client sign parts of the request (method, path, timestamp, nonce, and body) using a shared secret. Grape can verify the signature before processing the request. However, if the endpoint handling the request uses a user-provided identifier (e.g., /users/:id/resource/:resource_id) and only validates the HMAC without confirming that the authenticated subject owns or is authorized to access that specific resource, BOLA occurs. The signature proves the request was not tampered with and comes from a permitted client, but it does not imply the client is allowed to act on the target object.

Attack flow example: A client with a valid HMAC calls GET /api/v1/users/123/profile. The server verifies the HMAC successfully, but the endpoint returns data for user 123 without confirming the requesting user is user 123 or has permission. If the client simply changes the numeric ID to 124, and the server continues to serve data without ownership checks, information disclosure occurs. Because the HMAC validation passes, the request appears legitimate, bypassing weaker authorization logic that might otherwise block access. This pattern commonly appears when developers assume authenticated requests equate to properly scoped authorization.

In Grape, this can happen when helper methods resolve the current user from the HMAC verification but subsequent logic uses params directly without scoping to that user. For example, fetching a record via Model.find(params[:id]) without ensuring the record.user_id matches the current user derived from the HMAC creates an authorization gap. The presence of HMAC signatures does not automatically enforce object-level constraints; developers must explicitly add ownership or tenant checks after signature validation to prevent BOLA.

To remediate BOLA when using HMAC Signatures in Grape, ensure that after signature validation and user resolution, every data access is scoped to the authorized subject. Do not rely on the HMAC alone to enforce object-level permissions. Below are concrete code examples demonstrating secure patterns.

First, a typical HMAC verification setup in Grape that extracts identity and validates the signature. This example uses a before block to authenticate the request and set current_user. Note that authentication and authorization are separated intentionally.

class MyEntity < Grape::Entity
  expose :id, :name, :email
end

class Base < Grape::API
  helpers do
    def verify_hmac_signature
      timestamp = request.env['HTTP_X_TIMESTAMP']
      nonce = request.env['HTTP_X_NONCE']
      signature = request.env['HTTP_X_SIGNATURE']
      message = "#{request.request_method}#{request.fullpath}#{timestamp}#{nonce}#{request.body.read}"
      # rewind body for downstream use in case needed
      request.body.rewind
      expected = OpenSSL::HMAC.hexdigest('sha256', shared_secret, message)
      halt 401, { error: 'invalid_signature' }.to_json unless secure_compare(expected, signature)
      timestamp, nonce
    end

    def secure_compare(a, b)
      return false unless a.bytesize == b.bytesize
      l = a.unpack 'C*'
      res = 0
      b.each_byte { |byte| res |= byte ^ l.shift }
      res == 0
    end

    def current_user
      @current_user ||= User.find_by(hmac_key: request.env['HTTP_X_CLIENT_KEY'])
    end
  end

  before do
    verify_hmac_signature
    # At this point current_user is set, but we still need to scope data access
  end
end

Now, an endpoint that safely scopes resource access to the authenticated subject. Instead of using params[:id] directly to fetch a record, we scope by current_user.id. This ensures that even if an attacker manipulates the URL parameter, they cannot access another user’s resources.

class ProfileEndpoint < Base
  desc 'Get current user profile'
  params do
    requires :id, type: Integer, desc: 'User ID', required: false
  end
  get '/users/:id/profile' do
    user_id = params[:id] || current_user.id
    profile = current_user.profile # scoped by association
    error!('Forbidden', 403) unless profile.user_id == current_user.id
    present profile, with: MyEntity
  end
end

For nested resources, always scope through the parent to enforce ownership. This pattern prevents BOLA by ensuring the child record belongs to the authorized parent, which in turn belongs to the current user verified via HMAC.

class ProjectEndpoint < Base
  desc 'Get project tasks'
  params do
    requires :project_id, type: Integer, desc: 'Project ID'
  end
  get '/projects/:project_id/tasks/:id' do
    project = Project.where(user_id: current_user.id).find_by(id: params[:project_id])
    error!('Project not found or unauthorized', 403) unless project
    task = project.tasks.find_by(id: params[:id])
    error!('Task not found or unauthorized', 403) unless task
    present task, with: MyEntity
  end
end

In summary, HMAC Signatures in Grape provide request integrity and client authentication, but they must be paired with explicit object ownership checks. Always resolve the subject from the HMAC context and scope every data access to that subject to eliminate BOLA.