Bola Idor in Hanami with Dynamodb

Broken Object Level Authorization (BOLA) occurs when an application fails to enforce authorization checks between a user and the specific resource they are attempting to access. In Hanami applications that use Amazon DynamoDB as the persistence layer, this risk is amplified when object identifiers are predictable or when authorization logic is applied inconsistently across data access paths.

DynamoDB stores items in tables with partition keys and optional sort keys. If Hanami routes expose DynamoDB key attributes directly in URLs (for example, /users/:user_id/records/:record_id) and the backend retrieves items using those keys without verifying that the authenticated subject owns the target item, BOLA is introduced. Even when using the AWS SDK for Ruby, developers might write code that does a get_item by key and then skip an ownership check because they assume the key itself is sufficient proof of authorization.

In Hanami, resource classes often encapsulate data access. If a method such as RecordRepository#find uses the incoming ID parameters to build a DynamoDB key and fetch an item, but does not cross-reference the current user’s ID with the item’s user_id attribute, the endpoint becomes vulnerable. Attackers can modify the ID in the request (e.g., incrementing a numeric key or guessing a UUID) and retrieve or operate on other users’ records. Because DynamoDB returns the item when the key exists, Hanami must implement explicit authorization checks after retrieval to ensure the item belongs to the requesting user or is otherwise permitted by role or scope.

Moreover, DynamoDB’s flexible schema can encourage storing related data in a single item or using composite keys. If Hanami models permissions at the item level but the item contains multiple subresources, missing granular checks can lead to BOLA across those subresources. For example, a single DynamoDB item might store user profile and settings; if Hanami exposes endpoints to update each logical section by an index within the item without verifying scope, an attacker might update settings they should not touch.

An additional concern is unauthenticated LLM endpoint detection if Hanami services are also exposed to AI tooling. While this is orthogonal to classic BOLA, it highlights how broad the attack surface can be when APIs expose predictable keys without robust authorization and input validation checks.

To mitigate BOLA in Hanami with DynamoDB, ensure that every data access path includes explicit authorization checks that tie the resource to the current subject. Avoid relying on key-based obscurity, and instead enforce ownership or role-based access control at the application layer.

Example: Authorized retrieval with DynamoDB and Hanami

Assume a User model and a Record model where each record has a user_id attribute. The repository should accept both the DynamoDB key and the current user, then verify ownership before returning the item.

require 'aws-sdk-dynamodb'

class RecordRepository
  def initialize(table_name = 'records')
    @dynamodb = Aws::DynamoDB::Client.new(region: 'us-east-1')
    @table = table_name
  end

  # Fetch a record only if it belongs to the given user_id
  def find(user_id, record_id)
    resp = @dynamodb.get_item(
      table_name: @table,
      key: {
        'pk' => { s: "RECORD##{record_id}" },
        'sk' => { s: "USER##{user_id}" }
      }
    )
    item = resp.item
    # Even if the key matches, ensure the item exists and belongs to the user.
    # Using a composite key where user_id is part of the key helps, but explicit checks are still required.
    raise Hanami::InvalidInput, 'Record not found' if item.empty?

    # Additional authorization: confirm the user_id in the item matches the caller.
    # This is essential when key design alone does not enforce ownership.
    owned_by_current_user = item['user_id'] == user_id
    raise Hanami::Unauthorized, 'Access denied' unless owned_by_current_user

    OpenStruct.new(
      id: item['id'],
      user_id: item['user_id'],
      data: item['data']
    )
  end
end

Example: Update with ownership verification

When updating an item, re-fetch and validate ownership. Do not trust client-supplied keys alone.

class RecordRepository
  # ... initialize as above

  def update(user_id, record_id, update_attrs)
    record = find(user_id, record_id) # reuse the authorized fetch
    # Proceed with update using the same key design
    @dynamodb.update_item(
      table_name: @table,
      key: {
        'pk' => { s: "RECORD##{record_id}" },
        'sk' => { s: "USER##{user_id}" }
      },
      update_expression: 'set data = :data',
      expression_attribute_values: {
        ':data' => { s: update_attrs[:data] }
      }
    )
  rescue Aws::DynamoDB::Errors::ConditionalCheckFailedException
    raise Hanami::Unauthorized, 'Update not permitted'
  end
end

Best practices to prevent BOLA with DynamoDB in Hanami

• Use composite keys where the user_id is part of the partition or sort key, but still perform explicit ownership checks.
• Centralize data access in repositories or gateways so authorization logic is not duplicated across controllers.
• Validate and sanitize all user-supplied identifiers before using them as DynamoDB keys.
• Apply the principle of least privilege to the IAM role used by Hanami so that even if an ID is guessed, the attacker cannot perform unauthorized actions at the AWS level.
• Log and monitor failed authorization attempts for anomalies that may indicate probing or brute-force attempts against record IDs.