Ssrf Server Side in Actix with Dynamodb

Server-side request forgery (SSRF) in an Actix-based service that interacts with DynamoDB can occur when user-supplied input is used to construct internal AWS API calls or HTTP fetches without strict validation. Because DynamoDB operations typically require AWS credentials and a well-formed endpoint, developers may inadvertently allow an attacker to influence the target host, path, or query parameters used by the backend HTTP client. In an Actix web application, this often manifests in handler code that accepts a URL or key parameter and passes it to a DynamoDB client or an internal HTTP request without restricting the allowed host or schema.

For example, if an endpoint accepts a DynamoDB table name or a conditional filter value that is forwarded to an HTTP call or AWS SDK operation, SSRF can be leveraged to make the server reach internal AWS metadata endpoints (e.g., 169.254.169.254) or arbitrary internal services. This risk is heightened when the application runs in an environment with an attached IAM role, because captured requests may escalate via AWS Signature V4 if credentials are discoverable. The SSRF attack surface is not introduced by DynamoDB itself but by how the Actix service builds and forwards requests that include user-influenced data used in table names, key condition expressions, or HTTP-based integrations such as Lambda invocations or S3 presigned URL generation.

middleBrick detects SSRF by correlating OpenAPI/Swagger specifications (including $ref resolution across 2.0, 3.0, and 3.1) with runtime behavior. For an Actix service using DynamoDB, scans check whether endpoints that accept or influence table identifiers, key parameters, or filter expressions also perform outbound HTTP calls to user-controlled hosts. Findings include severity, a description of the exposed surface, and remediation guidance that emphasizes input validation, allowlisting, and removing unnecessary forwarding of user input into AWS SDK or HTTP client calls.

To mitigate SSRF when using DynamoDB in Actix, ensure that all user-controlled input is validated and never directly interpolated into AWS SDK calls or HTTP requests. Use strict allowlists for table names, parameterize queries with strongly typed structures, and avoid passing raw strings into client constructors or HTTP URLs. Below are concrete, working examples in Rust using the official AWS SDK for Rust with Actix-web.

Example 1: Safe DynamoDB GetItem with validated table name

use actix_web::{web, HttpResponse, Result};
use aws_sdk_dynamodb::Client;
use aws_sdk_dynamodb::types::AttributeValue;

async fn get_item(
    client: web::Data,
    table_name: web::Path,
    key: web::Query>,
) -> Result<HttpResponse> {
    // Validate table name against an allowlist
    let allowed_tables = ["users", "orders", "products"];
    if !allowed_tables.contains(&table_name.as_str()) {
        return Ok(HttpResponse::BadRequest().body("Invalid table name"));
    }

    // Build key using strongly typed AttributeValue
    let mut key_map = std::collections::HashMap::new();
    for (k, v) in key.iter() {
        key_map.insert(k.clone(), AttributeValue::S(v.clone()));
    }

    let resp = client
        .get_item()
        .table_name(table_name.into_inner())
        .set_key(Some(key_map))
        .send()
        .await?;

    Ok(HttpResponse::Ok().json(resp.item.unwrap_or_default()))
}

Example 2: Safe DynamoDB Query with expression attribute values

use aws_sdk_dynamodb::types::AttributeValue;

async fn query_users(client: &Client, partition_key: &str) -> Result<Vec<AttributeValue>, aws_sdk_dynamodb::Error> {
    // Validate partition key format (e.g., UUID or email pattern)
    if !partition_key.contains('@') && !uuid::Uuid::parse_str(partition_key).is_ok() {
        return Err(aws_sdk_dynamodb::error::SdkError::construction_failure(
            "Invalid partition key format".into(),
        ));
    }

    let resp = client
        .query()
        .table_name("users")
        .key_condition_expression("pk = :v")
        .expression_attribute_values({
            let mut map = std::collections::HashMap::new();
            map.insert(":v".to_string(), AttributeValue::S(partition_key.to_string()));
            map
        })
        .send()
        .await?;

    Ok(resp.items.unwrap_or_default())
}

Example 3: Avoid forwarding user input to HTTP clients

use actix_web::HttpRequest;

// BAD: directly using user input in a URL
// let url = format!("https://{}", user_host);

// GOOD: whitelist allowed hosts and use a connector with strict TLS
async fn safe_internal_call(allowed_hosts: &[&str], host: &str) -> bool {
    allowed_hosts.contains(&host)
}

In addition to input validation, prefer environment-based configuration for AWS endpoints and credentials, and avoid passing user-controlled strings into URL builders used by the SDK or HTTP clients. middleBrick’s scans for an Actix + DynamoDB setup will highlight endpoints where user input reaches outbound requests and flag missing allowlisting, helping teams focus remediation on validation and strict schema usage.