Missing Tls in Axum with Dynamodb

When an Axum service communicates with DynamoDB without enforcing Transport Layer Security (TLS), credentials, tokens, and query parameters can traverse the network in cleartext. This typically occurs when the HTTP client used by Axum is configured without a TLS connector or is pointed at a non-HTTPS endpoint. An attacker who can observe or inject traffic on the network path can capture AWS access keys, session tokens, and the structure of DynamoDB table names, which may enable further attacks such as credential reuse or data exfiltration.

In a typical Axum handler, a developer might construct a DynamoDB client using the AWS SDK for Rust. If the client is built with default HTTPS endpoints but the runtime environment is misconfigured to use an HTTP proxy or a custom endpoint without TLS, requests to DynamoDB can be downgraded. Such misconfiguration effectively bypasses AWS Signature Version 4 protections over the wire, because the encryption in transit is not guaranteed. The risk is compounded in development or test environments where self-signed certificates are ignored, establishing a pattern that can carry into production.

Moreover, missing TLS can expose metadata and query patterns. Even if the AWS credentials are protected by other means, an observer can infer which DynamoDB tables are being accessed and the frequency of operations, enabling reconnaissance. In regulated contexts, this violates data-in-transit protections expected by frameworks such as OWASP API Top 10 (API2:2023 Broken Object Level Authorization often coexists with weak transport security) and can complicate compliance with PCI-DSS and SOC2, which require encryption of credentials and data in transit.

To remediate missing TLS in an Axum application that uses DynamoDB, ensure the AWS SDK client is configured to use HTTPS endpoints and enforce TLS verification. Do not disable certificate validation. Below is a concrete, working example using the official AWS SDK for Rust (aws-sdk-dynamodb) with hyper and TLS via rustls.

use aws_config::meta::region::RegionProviderChain;
use aws_sdk_dynamodb::Client;
use hyper::client::HttpConnector;
use hyper_rustls::HttpsConnector;
use std::sync::Arc;

async fn build_dynamodb_client() -> Client {
    // Use region provider chain; default to us-east-1 if not set
    let region_provider = RegionProviderChain::default_provider().or_else("us-east-1");
    
    // Build an HTTPS connector with rustls
    let https = HttpsConnector::with_native_roots().expect("Failed to create HTTPS connector");
    let hyper_client = hyper::Client::builder().build::<_, hyper::Body>(https);
    
    // Load AWS configuration with enforced HTTPS
    let config = aws_config::from_env()
        .region(region_provider)
        .http_client(Arc::new(hyper_client))
        .load()
        .await;
    
    Client::new(&config)
}

// Example handler in Axum that uses the secure client
async fn get_item_handler(
    client: web::Data,
    table_name: String,
    key: String,
) -> Result {
    let output = client
        .get_item()
        .table_name(&table_name)
        .key("id", aws_sdk_dynamodb::types::AttributeValue::S(key))
        .send()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    match output.item() {
        Some(item) => Ok(Json(item.clone())),
        None => Ok(StatusCode::NOT_FOUND.into()),
    }
}

If you must use a custom endpoint (for example, a proxy or an alternative storage backend), explicitly set the endpoint to an HTTPS URL and ensure the certificate chain is trusted. The following snippet shows how to configure a custom HTTPS endpoint safely:

use aws_sdk_dynamodb::config::{Endpoint, Region};
use aws_sdk_dynamodb::Client;

async fn build_dynamodb_client_with_custom_https_endpoint() -> Client {
    let region = Region::new("us-east-1");
    let endpoint = Endpoint::immutable(
        "https://dynamodb.us-east-1.amazonaws.com" // must be HTTPS
            .parse()
            .expect("Valid HTTPS endpoint"),
    );
    let config = aws_config::from_env()
        .region(Some(region))
        .endpoint_url(endpoint)
        .load()
        .await;
    Client::new(&config)
}

In CI/CD pipelines, integrate the middleBrick GitHub Action to validate that your API endpoints enforce TLS and that DynamoDB communications are not inadvertently downgraded. The GitHub Action can fail builds if security scores drop, helping prevent insecure configurations from reaching production. For local and IDE-driven workflows, the MCP Server allows you to scan APIs directly from your AI coding assistant, surfacing missing TLS risks as you develop.