Bola Idor in Grape with Dynamodb

Remediation centers on enforcing ownership at the point of data access. Always scope DynamoDB operations to the authenticated subject, and validate that the requested resource belongs to that subject before performing any operation.

1. Include the user identifier in the DynamoDB key design and queries. If your table uses a composite key where the partition key is user_id, ensure every request includes the current user’s ID:

resource :profiles do
  params do
    requires :profile_id, type: String
  end
  get ':profile_id' do
    profile_id = params[:profile_id]
    current_user_id = current_account.id # your auth/session helper

    dynamodb = Aws::DynamoDB::Client.new(region: 'us-east-1')
    resp = dynamodb.get_item(
      table_name: 'profiles',
      key: {
        profile_id: { s: profile_id },
        user_id:   { s: current_user_id }
      }
    )
    not_found! unless resp.item
    present resp.item
  end
end

In this pattern, the primary key includes user_id, so a mismatch means the item does not belong to the requester. If your table schema cannot be changed, enforce ownership by filtering query results with the user identifier:

resource :orders do
  params do
    requires :order_id, type: String
  end
  get ':order_id' do
    order_id = params[:order_id]
    current_user_id = current_account.id

    dynamodb = Aws::DynamoDB::Client.new(region: 'us-east-1')
    resp = dynamodb.get_item(
      table_name: 'orders',
      key: { order_id: { s: order_id } }
    )
    item = resp.item
    forbidden! unless item && item['user_id']&.fetch('S') == current_user_id
    present item
  end
end

2. When using GSIs, include the user identifier in both the index key and your queries. For example, if you have a GSI with partition key user_id, query with that key explicitly:

resource :messages do
  params do
    requires :message_id, type: String
  end
  get ':message_id' do
    message_id = params[:message_id]
    current_user_id = current_account.id

    dynamodb = Aws::DynamoDB::Client.new(region: 'us-east-1')
    resp = dynamodb.query(
      table_name: 'messages',
      index_name: 'user-message-index',
      key_condition_expression: 'user_id = :uid AND message_id = :mid',
      expression_attribute_values: {
        ':uid' => { s: current_user_id },
        ':mid' => { s: message_id }
      }
    )
    items = resp.items
    not_found! if items.empty?
    present items
  end
end

3. For destructive operations, repeat the ownership check immediately before the action and consider using conditional writes to prevent race conditions:

resource :items do
  params do
    requires :item_id, type: String
  end
  delete ':item_id' do
    item_id = params[:item_id]
    current_user_id = current_account.id

    dynamodb = Aws::DynamoDB::Client.new(region: 'us-east-1')
    # Ensure the item exists and belongs to the user before deleting
    begin
      dynamodb.delete_item(
        table_name: 'items',
        key: { item_id: { s: item_id } },
        condition_expression: 'user_id = :uid',
        expression_attribute_values: {
          ':uid' => { s: current_user_id }
        }
      )
    rescue Aws::DynamoDB::Errors::ConditionalCheckFailedException
      forbidden! 'Item not found or access denied'
    end
    { status: 'deleted' }
  end
end

These patterns ensure that every DynamoDB operation is bound to the authenticated subject, effectively mitigating BOLA/IDOR in Grape APIs. Defense in depth can be further strengthened by validating input formats, using least-privilege IAM roles for the DynamoDB client, and logging authorization failures for audit.