Insecure Direct Object Reference in Axum with Dynamodb

Insecure Direct Object Reference (BOLA/IDOR) occurs when an API exposes internal object references such as database keys or IDs in requests and fails to enforce that the requesting user is authorized to access that specific object. In an Axum application using Amazon DynamoDB as the persistence layer, this typically surfaces in routes that accept a user-supplied identifier (e.g., a note ID or record ID) and directly query DynamoDB without confirming that the resource belongs to the requester.

Consider an endpoint /users/{user_id}/notes/{note_id}. If the implementation retrieves the note by note_id from DynamoDB without verifying that the note’s user_id matches the authenticated subject’s ID, an attacker can iterate through note IDs and read other users’ notes. DynamoDB’s key-based model can make this subtle: a poorly designed partition key choice (e.g., using note_id as the partition key without a user_id prefix) can enable scanning across users, while a composite key design (e.g., partition key = user_id, sort key = note_id) can still allow unauthorized access if the application does not validate ownership on each request.

Axum’s extractor pattern can inadvertently contribute to the issue if route extractors provide the ID without tying it to the actor’s identity. For example, extracting note_id and using it in a DynamoDB GetItem or Query without a uniqueness constraint that includes the user context means the service performs the requested operation on the supplied reference, regardless of authorization. This becomes an IDOR when access control is applied at a coarse level (e.g., only at the API gateway or via coarse role checks) rather than at the resource level.

Additionally, if the API exposes secondary indexes or query endpoints that allow filtering by attributes other than the ownership partition key, an attacker may leverage those paths to reach data they should not see. DynamoDB’s flexibility in querying means that without explicit checks that the authenticated user’s identifier matches the partition key (or a required attribute in the item), each direct object reference is a potential IDOR vector.

For LLM-related endpoints, IDOR can also manifest if prompts, datasets, or model configurations are referenced by user-supplied identifiers without verifying that the authenticated actor owns the referenced asset. middleBrick’s LLM/AI Security checks include system prompt leakage detection and active prompt injection testing, which can help identify whether indirect object references in AI features expose cross-user data or enable unauthorized operations.

middleBrick can detect these IDOR patterns during a scan by correlating OpenAPI/Swagger definitions (including full $ref resolution) with runtime behavior, highlighting endpoints where object references are used without clear ownership validation. The scanner checks for missing authorization on per-resource operations and maps findings to frameworks such as OWASP API Top 10 and SOC2.

To remediate IDOR in an Axum service using DynamoDB, enforce ownership checks at the data-access layer so that every request validates that the authenticated subject has the right to access the referenced object. Prefer a composite key design where the partition key incorporates the user identifier, and ensure queries include the user context.

Example 1: Safe note retrieval using a composite key (partition key = user_id, sort key = note_id).

use aws_sdk_dynamodb::Client;
use axum::extract::Path;
use serde::Deserialize;

#[derive(Deserialize)]
pub struct NotePath {
    user_id: String,
    note_id: String,
}

pub async fn get_note_handler(
    Path(Path { user_id, note_id }): Path,
    client: &Client,
    // Assume caller_identity is obtained from your auth layer and passed in
    caller_identity: String,
) -> Result {
    // Ensure the authenticated caller matches the resource owner
    if caller_identity != user_id {
        return Err(ApiError::forbidden());
    }

    let resp = client
        .get_item()
        .table_name("Notes")
        .key("pk", aws_sdk_dynamodb::types::AttributeValue::S(format!("USER#{}", user_id))?)
        .key("sk", aws_sdk_dynamodb::types::AttributeValue::S(format!("NOTE#{}", note_id))?)
        .send()
        .await?;

    // Map item to domain model
    // ...
    Ok(note)
}

This ensures that the route cannot access another user’s note even if the note_id is guessed, because the partition key embeds the user_id and the handler explicitly checks that the caller matches the user_id portion.

Example 2: Querying a user-owned collection with a filter for additional attributes.

pub async fn list_user_notes(
    user_id: String,
    client: &Client,
    caller_identity: String,
) -> Result, ApiError> {
    if caller_identity != user_id {
        return Err(ApiError::forbidden());
    }

    let resp = client
        .query()
        .table_name("Notes")
        .key_condition_expression("pk = :pk")
        .expression_attribute_values(
            ":pk",
            aws_sdk_dynamodb::types::AttributeValue::S(format!("USER#{}", user_id)),
        )
        .send()
        .await?;

    // Deserialize items into Note
    // ...
    Ok(items)
}

Key remediation practices:

• Design DynamoDB keys so that ownership is part of the key (e.g., prefix partition/sort keys with user_id).
• Always validate that the authenticated subject matches the ownership attribute derived from the key or item data; never rely on client-supplied IDs alone.
• Avoid using global secondary indexes for operations that expose user-scoped data without ownership filters.
• For LLM endpoints that reference datasets or prompts, apply the same ownership checks before loading or modifying resources.
• Use middleBrick’s Pro plan for continuous monitoring and GitHub Action integration to catch regressions in CI/CD, ensuring IDOR checks remain part of your test suite as endpoints evolve.

Remember that middleBrick detects and reports these issues but does not fix them; it provides prioritized findings with remediation guidance to help your team implement secure access patterns.