Identification Failures in Axum with Dynamodb

Identification failures occur when an API fails to properly establish or enforce the identity of a principal across a request. In the Axum web framework combined with DynamoDB as the backend data store, this typically manifests as insecure direct object references (IDOR) or broken object-level authorization (BOLA). Axum is a Rust web framework that relies on explicit routing and extractor patterns; if route parameters or request metadata are used to construct DynamoDB keys without validating that the requesting user is authorized to access the corresponding item, the API exposes an identification failure.

Consider an Axum handler that extracts a user_id from the path and uses it directly as a DynamoDB key to fetch a profile:

// Risky: user_id from path used as DynamoDB key without ownership check
async fn get_profile(
    user_id: String,
    table: Extension,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let key = AttributeValue::from(user_id);
    let resp = table
        .get_item()
        .table_name("profiles")
        .set_key(Some(HashMap::from([("user_id", key)])))
        .send()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    // potentially return another user's profile if user_id is attacker-controlled
    todo!()
}

In this pattern, the API trusts the user_id provided in the request. An attacker can change the user_id to access other users’ profiles, which middleBrick would flag under the BOLA/IDOR checks and identify as an identification failure. Because DynamoDB does not enforce row-level permissions, it is the application’s responsibility to ensure that the authenticated subject matches the item’s ownership attributes. If the application conflates a user-supplied identifier with authorization, the unauthenticated or low-privilege attacker can enumerate or manipulate identifiers to access data they should not see.

Identification failures can also arise when using DynamoDB secondary indexes without validating the parent item ownership. For example, querying a GSI to retrieve items by an attribute like email can return records belonging to other tenants if the tenant context is not enforced in the query key condition and in the application logic:

// Risky: GSI query without tenant context enforcement
async fn list_items(
    email: String,
    tenant_id: String,
    table: Extension,
) -> Result<Vec<Item>, (StatusCode, String)> {
    let key_condition = format!("email = :email and tenant_id = :tenant_id");
    let resp = table
        .query()
        .table_name("items")
        .index_name("email-index")
        .key_condition_expression(key_condition.as_str())
        .expression_attribute_values(HashMap::from([
            (":email", AttributeValue::from(email)),
            (":tenant_id", AttributeValue::from(tenant_id)),
        ]))
        .send()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    // If tenant_id is not verified against the authenticated session, cross-tenant data may be returned
    todo!()
}

Even when a tenant_id is present in the query, if the tenant context is derived from an unverified source (e.g., a header supplied by the client), an attacker can supply a different tenant_id to pivot across organizations. middleBrick’s BOLA/IDOR checks and its analysis of the unauthenticated attack surface would detect that the API allows identification-based access control bypass in such configurations.

Identification failures are not limited to path parameters; they can also occur in how the API manages sessions or tokens. If an Axum application issues JWTs that contain a user identifier but does not validate authorization at the DynamoDB layer on each request, an attacker who obtains a token can reuse it to identify and probe other user identifiers. MiddleBrick’s authentication and BOLA checks would flag missing server-side authorization even when token validation appears present.

To remediate identification failures in Axum with DynamoDB, enforce strict ownership checks and ensure that every DynamoDB operation includes the correct authorization context derived from the authenticated subject rather than from client-supplied identifiers. Below are concrete, safe patterns using the AWS SDK for Rust with Axum.

1. Enforce ownership by mapping authenticated subject to DynamoDB key

Instead of using a path parameter as the key, resolve the user identifier from the authenticated session (e.g., from a JWT or session store) and use that to build the DynamoDB key:

use aws_sdk_dynamodb::Client;
use axum::{extract::Extension, routing::get, Json, Router};
use serde::Deserialize;

#[derive(Deserialize)]
struct Claims {
    sub: String, // authenticated subject
}

async fn get_profile_auth(
    Extension(client): Extension,
    // In practice, extract claims from a validated token/session
    claims: Claims,
) -> Result<Json<serde_json::Value>, (StatusCode, String)> {
    let key = AttributeValue::from(claims.sub);
    let resp = client
        .get_item()
        .table_name("profiles")
        .set_key(Some(HashMap::from([("user_id", key)])))
        .send()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    match resp.item() {
        Some(item) => Ok(Json(serde_dynamodb::from_attrs(item.clone()).map_err(|e| {
            (StatusCode::INTERNAL_SERVER_ERROR, e.to_string())
        })?)),
        None => Err((StatusCode::NOT_FOUND, "Profile not found".to_string())),
    }
}

This ensures the key used for DynamoDB is derived from the server-side identity, not from user-controlled path parameters.

2. Combine GSI queries with tenant and ownership validation

When using a Global Secondary Index, include both the indexed attribute and a verified tenant or owner attribute in the key condition, and re-validate on the client side:

async fn list_items_for_tenant(
    Extension(client): Extension,
    // authenticated tenant context derived server-side
    tenant_id: String,
    email: String,
) -> Result<Vec<serde_json::Value>, (StatusCode, String)> {
    let resp = client
        .query()
        .table_name("items")
        .index_name("email-index")
        .key_condition_expression("email = :email AND tenant_id = :tenant_id")
        .expression_attribute_values(HashMap::from([
            (":email", AttributeValue::from(email)),
            (":tenant_id", AttributeValue::from(tenant_id.clone())),
        ]))
        .send()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let items: Vec<serde_json::Value> = resp
        .items()
        .into_iter()
        .map(|item| serde_json::to_value(item).map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string())))
        .collect::

async fn get_item_checked(
    item_id: String,
    Extension(client): Extension,
    Extension(claims): Extension, // authenticated subject and roles
) -> Result<Json<serde_json::Value>, (StatusCode, String)> {
    let key = AttributeValue::from(item_id);
    let resp = client
        .get_item()
        .table_name("items")
        .set_key(Some(HashMap::from([("item_id", key)])))
        .send()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let item = resp.item().ok_or((StatusCode::NOT_FOUND, "Item not found"))?;
    let owner = item.get("owner").and_then(|v| v.as_s()).unwrap_or_default();
    if owner != claims.sub {
        return Err((StatusCode::FORBIDDEN, "Access denied".to_string()));
    }
    Ok(Json(serde_json::to_value(item).map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?))
}