Path Traversal in Actix with Dynamodb

Path Traversal occurs when an API uses attacker-controlled input to construct file system or object paths without proper validation. In an Actix web service that stores or retrieves objects from DynamoDB, this typically manifests through endpoints that accept a key or identifier (e.g., a document ID or file path) and use it to build a DynamoDB key or to locate a local resource before writing to or reading from DynamoDB.

Consider an endpoint like /documents/{doc_id} where doc_id is passed directly into a DynamoDB GetItem request. If the application does not validate that doc_id is a simple identifier and instead uses it to build a file path for local caching or to form a DynamoDB key with additional prefixes/suffixes, an attacker can supply sequences like ../../../etc/passwd or encoded variants to traverse directories. Even when the data ultimately resides in DynamoDB, unsafe construction of request parameters can lead to unauthorized access to unrelated items or local filesystem interactions if the application mixes path-based logic with DynamoDB key logic.

For example, if the code builds a DynamoDB key by concatenating a user-supplied value with a fixed prefix (e.g., tenant_123/), an attacker providing ../../../secret could produce keys such as tenant_123/../../../secret. While DynamoDB keys themselves do not traverse directories, such logic often indicates flawed parameter handling that can expose more than intended, including enumeration of other tenants or objects. Moreover, if the application uses the same input to reference local assets (thumbnails, metadata files) before storing or retrieving the DynamoDB item, the traversal risk extends to the filesystem, potentially exposing configuration files or other sensitive data referenced by the constructed path.

In the context of middleBrick’s checks, this scenario would be flagged under BOLA/IDOR and Input Validation categories. The scan would observe whether the API surface allows path-like inputs to influence key construction or file resolution without canonicalization and strict allowlisting. Because middleBrick tests unauthenticated attack surfaces, it can detect endpoints where traversal patterns in requests lead to unexpected behavior or information exposure without requiring credentials.

To prevent Path Traversal in an Actix service that uses DynamoDB, validate and sanitize all user inputs before using them to construct DynamoDB keys or local paths. Use strict allowlists (e.g., alphanumeric plus limited symbols), reject encoded traversal sequences, and avoid building paths by string concatenation. Prefer structured key designs and isolate filesystem operations from DynamoDB key logic.

Below are concrete, realistic examples for an Actix handler that retrieves an item from DynamoDB using a document ID safely.

Validation and canonicalization

Validate the document ID to ensure it contains only expected characters and does not include path traversal elements. Do not rely on user input to build filesystem paths.

use actix_web::{web, HttpResponse, Result};
use regex::Regex;

/// Validate document ID: only alphanumeric, hyphens, and underscores, length 1..128
fn is_valid_doc_id(doc_id: &str) -> bool {
    let re = Regex::new(r"^[a-zA-Z0-9_-]{1,128}$").unwrap();
    re.is_match(doc_id)
}

async fn get_document(path: web::Path<String>) -> Result<HttpResponse> {
    let doc_id = path.into_inner();
    if !is_valid_doc_id(&doc_id) {
        return Ok(HttpResponse::BadRequest().body("Invalid document ID"));
    }
    // Proceed to DynamoDB call with the validated doc_id
    Ok(HttpResponse::Ok().body(format!("Fetching document: {}", doc_id)))
}

Safe DynamoDB key construction

Use a fixed prefix and the validated ID as the key attribute value. Do not concatenate user input into file paths or into keys with variable directory components.

use aws_sdk_dynamodb::Client;
use aws_sdk_dynamodb::types::AttributeValue;

async fn get_item_from_dynamodb(client: &Client, doc_id: &str) -> Result<Option<aws_sdk_dynamodb::types::Item>, aws_sdk_dynamodb::Error> {
    let resp = client.get_item()
        .table_name("Documents")
        .key("doc_id", AttributeValue::S(doc_id.to_string()))
        .send()
        .await?
        .item;
    Ok(resp)
}

// Usage inside handler after validation:
// let item = get_item_from_dynamodb(&client, &doc_id).await?;

Avoid mixing filesystem paths with DynamoDB keys

If you need to store or reference local files, derive paths from server-side configuration or non-user input, and keep them separate from DynamoDB key logic. Never directly use user input in filesystem operations.

use std::path::{Path, PathBuf};

fn safe_thumbnail_path(server_base: &Path, doc_id: &str) -> PathBuf {
    // server_base is configured server-side, not from user input
    server_base.join("thumbnails").join(format!("{}.jpg", doc_id))
}

By combining strict input validation, fixed key schemas, and separation of concerns between object storage keys and filesystem paths, you mitigate Path Traversal risks while retaining DynamoDB integration within Actix services.