Bola Idor in Axum with Dynamodb

Broken Object Level Authorization (BOLA) occurs when an API exposes object references that allow one user to access or modify data belonging to another user. In an Axum service using Amazon DynamoDB as the persistence layer, this typically arises when a record’s primary key or sort key is predictable (e.g., a user ID) and authorization checks are missing or incorrectly applied before performing a GetItem or Query operation.

DynamoDB’s key design—partition key and optional sort key—means that primary key values are often directly meaningful identifiers. If an endpoint accepts a user_id as a path parameter and uses it directly as the partition key without verifying that the authenticated actor matches that user_id, an attacker can tamper with the identifier to access other users’ items. This is a classic BOLA/IDOR pattern: the parameter tampering vector exploits weak authorization tied to object ownership.

Consider an endpoint like GET /users/{user_id}/profile. If the Axum handler builds a DynamoDB request using user_id as the key without confirming the requestor’s identity matches user_id, any authenticated user can enumerate or retrieve other profiles. Because DynamoDB does not enforce ownership semantics, the authorization burden falls entirely on the application. Further, DynamoDB queries that expose sort keys without proper filtering can widen the impact: an attacker might iterate over sort key ranges to access related sensitive records that should be isolated per user or per tenant.

The risk is compounded when the API exposes secondary indexes or when query patterns do not enforce a mandatory filter on ownership attributes (e.g., owner_id). Even if the primary key is not directly user-controlled, a missing or inconsistent check on an attribute like tenant_id can allow horizontal privilege escalation across users sharing the same partition structure. In Axum, this often maps to routes like /api/v1/accounts/{account_id}/settings where account_id is used as a DynamoDB key without validating that the requester belongs to that account.

DynamoDB-specific behaviors also play a role. Strongly consistent reads can reduce the window for race conditions, but they do not replace authorization. Conditional writes using ConditionExpression can prevent some overwrite issues but do not mitigate read BOLA. Moreover, sparse indexes or attributes that indicate ownership are only effective if the application consistently enforces checks; missing checks in one handler create an exploitable path across the API surface.

To summarize, the combination of Axum routing with DynamoDB key patterns and missing or incorrect ownership validation creates BOLA/IDOR: predictable keys, lack of per-request authorization, and overly broad query patterns allow attackers to traverse object relationships they should not access. Remediation requires tying every database operation to the authenticated subject and enforcing least-privilege access controls at the data layer.

Remediation centers on ensuring that every DynamoDB request is scoped to the authenticated subject and that authorization is verified before any database operation. Below are concrete Axum handler patterns and DynamoDB SDK usage that enforce ownership and mitigate BOLA.

1. Enforce ownership with authenticated subject

Always derive the allowed key from the authenticated identity rather than from user input. For example, if you use JWTs with a sub claim representing the user ID, bind the request path parameter to a route but validate that the subject matches the intended resource.

use axum::{routing::get, Router};
use aws_sdk_dynamodb::Client;
use std::sync::Arc;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};

async fn profile_handler(
    axum::extract::Path(user_id): axum::extract::Path,
    auth_header: axum::extract::State<Option

async fn list_user_items(
    axum::extract::Path(_user_id): axum::extract::Path,
    auth_header: axum::extract::State<Option<String>>,
    client: axum::extract::State<Arc<Client>>,
) -> Result<impl axum::response::IntoResponse, (axum::http::StatusCode, String)> {
    let token = auth_header.ok_or((axum::http::StatusCode::UNAUTHORIZED, "missing auth"))?;
    let claims: Claims = decode_and_validate(&token)?;
    // Use subject as partition key; do not allow caller to choose it
    let resp = client.query()
        .table_name("user_items")
        .key_condition_expression("owner_id = :uid")
        .expression_attribute_values(":uid", aws_sdk_dynamodb::types::AttributeValue::S(claims.sub.clone()))
        .send()
        .await
        .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    Ok(axum::Json(resp))
}

async fn get_tenant_data(
    axum::extract::State<Arc<Client>>,
    axum::extract::Json(payload): axum::extract::Json<TenantRequest>,
    auth_header: axum::extract::State<Option<String>>,
) -> Result<impl axum::response::IntoResponse, (axum::http::StatusCode, String)> {
    let token = auth_header.ok_or((axum::http::StatusCode::UNAUTHORIZED, "missing auth"))?;
    let claims: Claims = decode_and_validate(&token)?;
    // Assume tenant_id is mapped from claims, not from user input
    let resp = client.query()
        .index_name("tenant_index")
        .table_name("resources")
        .key_condition_expression("tenant_pk = :tid AND begins_with(sort_key, :prefix)")
        .expression_attribute_values(
            ":tid", aws_sdk_dynamodb::types::AttributeValue::S(claims.tenant_id.clone())
        )
        .expression_attribute_values(
            ":prefix", aws_sdk_dynamodb::types::AttributeValue::S(payload.prefix)
        )
        .send()
        .await
        .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    Ok(axum::Json(resp))
}