Bola Idor in Phoenix with Dynamodb

BOLA (Broken Object Level Authorization) / IDOR occurs when an API exposes object identifiers and does not enforce that the authenticated subject is authorized to access the specific instance. In a Phoenix application using Amazon DynamoDB as the persistence layer, this typically arises from constructing DynamoDB key conditions or queries directly from user-supplied parameters such as :user_id or :id without verifying that the requesting actor owns or is permitted to interact with that object.

For example, consider a Phoenix controller that retrieves a user profile by an id from the URL while the request is authenticated with a different user’s token. If the implementation builds a DynamoDB query like {"KeyConditionExpression" => "user_id = :uid AND id = :id", "ExpressionAttributeValues" => {:uid => current_user.id, :id => id}}, the service trusts that the caller may supply any :id. Because DynamoDB returns the item if the composite key matches, the endpoint inadvertently allows one user to read or modify another user’s record when the second index attribute (e.g., id) is predictable or known, creating an IDOR via DynamoDB’s key-based access pattern.

This combination is especially common in Phoenix services that use DynamoDB with composite keys, where the partition key might represent the tenant or user scope and the sort key represents the object identifier. If authorization checks are limited to verifying that the partition key matches the current user but the application later indexes or queries other objects using sort key values supplied by the client, BOLA can occur across related objects. Similarly, APIs that expose search or scan endpoints without scoping requests to the authenticated subject’s data range can inadvertently expose other users’ items, because DynamoDB does not automatically enforce ownership at the query level.

Another scenario involves shared indexes or secondary global indexes where access controls are not consistently applied. A developer might enforce ownership on the base table but forget to apply equivalent constraints on a GSI that uses different key attributes. If the GSI key incorporates a user identifier that is not validated, an attacker can manipulate query parameters to traverse across users or roles, leveraging DynamoDB’s efficient index lookups to enumerate or access unauthorized data.

Real-world attack patterns mirror the OWASP API Top 10:2023 category A1: Broken Object Level Authorization. Insecure direct object references in API parameters, predictable identifiers, and missing per-request authorization checks are root causes. When combined with DynamoDB’s fast key-value access, these weaknesses allow attackers to pivot across resources, escalate access, or exfiltrate sensitive information without needing to exploit implementation bugs beyond authorization logic.

Remediation focuses on ensuring that every DynamoDB request is scoped to the requesting subject and that authorization is verified before constructing the key expression. Below are concrete, idiomatic examples using the dynamo_db library in Phoenix/Elixir.

1. Enforce ownership in the key condition

Always include the authenticated subject as part of the partition key and validate it server-side before issuing the query.

def get_user_profile(conn, %{"id" => id}) do
  user_id = conn.assigns.current_user.id

  # Ensure the requested id belongs to the authenticated user
  if !valid_user_id?(user_id, id) do
    send_resp(conn, :forbidden, "Unauthorized")
  else
    query = %DynamoDB.Query{
      table: "profiles",
      key_condition_expression: "user_id = :uid AND id = :pid",
      expression_attribute_values: %{
        ":uid" => user_id,
        ":pid" => id
      }
    }

    case DynamoDB.query(query) do
      {:ok, %{items: [profile]}} -> json(conn, profile)
      {:ok, %{items: []}} -> send_resp(conn, :not_found, "Not found")
      {:error, reason} -> send_resp(conn, :internal_server_error, inspect(reason))
    end
  end
end

2. Use a secure wrapper for primary key access

Create a domain function that encapsulates authorization and DynamoDB retrieval to avoid accidental misuse elsewhere in the codebase.

defmodule ProfileAccess do
  alias DynamoDB.Query
  alias MyApp.Accounts

  def fetch_profile_for_user(current_user_id, profile_id) do
    with true <- Accounts.profile_accessible?(current_user_id, profile_id),
         %Query{} = query <- build_query(current_user_id, profile_id) do
      DynamoDB.query(query)
    else
      false -> {:error, :unauthorized}
      nil -> {:error, :not_found}
    end
  end

  defp build_query(user_id, profile_id) do
    %Query{
      table: "profiles",
      key_condition_expression: "user_id = :uid AND id = :pid",
      expression_attribute_values: %{
        ":uid" => user_id,
        ":pid" => profile_id
      }
    }
  end
end

3. Protect Global Secondary Index (GSI) queries

If you must query a GSI, repeat the ownership check using the same subject scope. Do not rely on the GSI key alone for authorization.

def search_user_items(conn, %{"category" => category}) do
  user_id = conn.assigns.current_user.id

  query = %DynamoDB.Query{
    table: "items",
    index_name: "category-user-index",
    key_condition_expression: "category = :cat AND user_id = :uid",
    expression_attribute_values: %{
      ":cat" => category,
      ":uid" => user_id
    }
  }

  case DynamoDB.query(query) do
    {:ok, %{items: items}} -> json(conn, items)
    _ -> send_resp(conn, :not_found, "No items")
  end
end

4. Validate and normalize identifiers

Avoid accepting raw IDs that can be guessed or enumerated. Use UUIDs or opaque identifiers, and map them to internal scoped keys before querying DynamoDB.

def resolve_id(user_id, external_id) do
  # Map external_id to internal DynamoDB key scoped to user_id
  # This prevents IDOR by decoupling public identifiers from storage keys
  Repo.one!(from i in Item, where: i.external_id == ^external_id and i.user_id == ^user_id, select: i.dynamodb_key)
end

5. Apply middleware checks in Phoenix

Use a plug to verify ownership for sensitive routes before reaching the controller.

defmodule MyAppWeb.EnsureOwnershipPlug do
  import Plug.Conn

  def init(opts), do: opts

  def call(conn, _opts) do
    resource_id = conn.params["id"] || conn.path_params["id"]
    if resource_accessible?(conn.assigns.current_user, resource_id) do
      conn
    else
      send_resp(conn, :forbidden, "Access denied")
      halt(conn)
    end
  end
end

By combining these patterns—scoped queries, centralized access functions, strict validation, and middleware checks—you mitigate BOLA/IDOR risks in a Phoenix service backed by DynamoDB without relying on the database to enforce ownership implicitly.