Path Traversal in Axum with Dynamodb

Path Traversal in an Axum service that uses DynamoDB typically occurs when user-controlled path components are used to build DynamoDB request keys without strict validation or canonicalization. Axum routes often capture parameters such as file_id or user_id and forward them to a data layer that stores objects keyed by string identifiers. If the application constructs a DynamoDB key (e.g., a partition key or sort key) by concatenating user input with a prefix like user/, an attacker can supply sequences like ../../../secret to traverse logical boundaries and access or overwrite unintended items.

Because DynamoDB is a managed NoSQL store, path traversal does not manifest as filesystem access, but as unintended access to items outside the expected scope. For example, an Axum handler might do:

let key = format!("user/{}", user_input); // user_input could be ../../../admin
let _ = dynamodb_client.get_item()
    .table_name("AppData")
    .set_key(Some(serialize_key(&key)))
    .send()
    .await;

Here, a malicious user_input can change the effective key to user/../../../admin, which may resolve to a different logical key depending on how the application normalizes paths or constructs composite keys. If the application also uses the same key prefix for authorization checks (e.g., verifying that a requested resource belongs to the caller), but performs those checks after key construction, an Insecure Direct Object Reference (IDOR) or BOLA can be triggered. This maps to the BOLA/IDOR and Property Authorization checks in middleBrick’s 12 security checks, where unauthenticated or insufficiently scoped access to items is detected.

Moreover, DynamoDB’s flexible schema and lack of native directory semantics can amplify the issue: unlike a filesystem, there is no inherent concept of parent or child directories, so developers must enforce containment in application logic. If normalization is inconsistent between route parameters, key construction, and authorization logic, an attacker can exploit subtle mismatches. middleBrick’s OpenAPI/Swagger analysis (supporting 2.0, 3.0, 3.1 with full $ref resolution) can surface these mismatches by cross-referencing spec definitions with runtime behavior, highlighting endpoints where path parameters flow into DynamoDB key construction without strict allowlists.

In Axum, common contributing patterns include:

• Using raw path segments to form DynamoDB keys without validating against a whitelist of safe characters.
• Concatenating user input with static prefixes to form partition keys or sort keys.
• Failing to scope queries to a tenant or user identifier, allowing a crafted path to reach another tenant’s data.

These patterns are flagged by middleBrick’s checks for BOLA/IDOR, BFLA/Privilege Escalation, and Property Authorization, which emphasize scoping each DynamoDB request to the minimum required set of attributes and enforcing ownership explicitly.

Remediation focuses on strict validation, canonical key construction, and scoping each DynamoDB operation to the correct identity context. In Axum, define path extractors that validate input before it reaches business logic, and enforce ownership at the data layer.

1. Validate and sanitize path parameters using allowlists. For identifiers that represent user-owned resources, use a regex or a type that guarantees safety:

use axum::extract::Path;
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
struct ItemId(String);

impl TryFrom for ItemId {
    type Error = &'static str;
    fn try_from(value: String) -> Result {
        // Allow only alphanumeric, underscore, and hyphen; reject path separators
        if value.chars().all(|c| c.is_ascii_alphanumeric() || c == '_' || c == '-') {
            Ok(ItemId(value))
        } else {
            Err("invalid item id")
        }
    }
}

Then in your route:

async fn get_item(
    Path(item_id): Path,
    // ... other extractors
) -> Result {
    let key = format!("user/{}", item_id.0);
    // proceed with DynamoDB call using the canonical key
}

2. Scope DynamoDB requests with explicit ownership. Include a user or tenant identifier as part of the key and enforce it at query time:

use aws_sdk_dynamodb::types::AttributeValue;

async fn get_user_item(
    user_id: String,
    item_id: ItemId,
    client: &aws_sdk_dynamodb::Client,
) -> Result, AppError> {
    let partition_key = format!("user/{}", user_id);
    let sort_key = format!("item/{}", item_id.0);
    let resp = client.get_item()
        .table_name("AppData")
        .key(
            "PK",
            AttributeValue::S(partition_key),
        )
        .key(
            "SK",
            AttributeValue::S(sort_key),
        )
        .send()
        .await?
        .item
        .map(|attrs| deserialize_item(&attrs))
        .transpose()?;
    Ok(resp)
}

3. Avoid concatenating untrusted input into composite keys. Instead, map user input to a controlled key space using a lookup or a deterministic encoding:

use uuid::Uuid;

fn safe_key(user_id: &str, external_id: &str) -> String {
    // Use a deterministic, non-hierarchical key scheme
    let hash = md5::compute(format!("{}:{}", user_id, external_id));
    format!("I-{}", hex::encode(hash))
}

4. Enforce authorization before and after the DynamoDB call. Even when the key is constructed safely, verify that the requesting user has permission to access the target item. middleBrick’s checks for BOLA/IDOR and Property Authorization can be validated in tests by asserting that scoped requests reject cross-tenant identifiers.

5. Use middleware or extractor guards to reject paths containing traversal patterns early. For example, reject any parameter containing .. or leading slashes that could indicate attempts to bypass route constraints.

By combining strict input validation, canonical key construction, and explicit ownership checks, you reduce the risk of path-style traversal and IDOR when Axum interacts with DynamoDB. middleBrick’s scans can verify that these controls are present by analyzing your OpenAPI spec and comparing it against runtime behavior, ensuring that path parameters do not flow unchecked into key construction.