Timing Attack in Axum with Dynamodb

A timing attack in an Axum service that calls DynamoDB can occur when response times vary based on secret-sensitive operations, such as HMAC verification or user existence checks. Axum, as a Rust web framework, does not inherently introduce timing vulnerabilities, but the way application logic interacts with DynamoDB can create observable timing differences.

Consider a login flow where a user-supplied username is first retrieved from DynamoDB. If the request for a non-existent user completes faster than a request for an existing user (because the database returns early), an attacker can infer valid usernames. Even when a constant-time comparison is used after retrieval, the network round-trip time to DynamoDB can differ depending on whether the item exists, especially under variable network conditions. These small differences can be amplified when the attacker sends many requests and measures latency with high precision.

In Axum, handlers are typically asynchronous and may use SDK clients like the AWS SDK for Rust to perform DynamoDB operations. If the application performs early filtering or branching based on the presence of an item (e.g., returning a generic error only after confirming the item exists), the timing side channel is exposed. For example, fetching an item by primary key and then conditionally proceeding to password verification means an authenticated attacker can infer whether a given partition key exists by measuring request duration. Although DynamoDB itself does not leak user enumeration via timing in a well-designed schema, the application layer can reintroduce the risk through conditional logic and non-constant-time handling.

Another scenario involves DynamoDB conditional writes or query patterns that return variable latency depending on item size or index usage. If an Axum endpoint uses a query that filters on a non-key attribute and returns a variable number of items, the time to serialize and iterate results can differ. When combined with authentication or authorization logic that short-circuits on failure, these variations can disclose information about data presence or structure to a remote attacker.

Real-world attack patterns like CVE-2023-XXXX (illustrative) demonstrate how timing differences in API authentication endpoints can leak information about account validity. In the context of Axum and DynamoDB, the risk is not in the database protocol itself but in how the service orchestrates calls and responses. Mitigation requires ensuring that operations which could be subject to timing analysis follow constant-time patterns and that network-level variance is minimized through consistent request paths.

To prevent timing-related information leakage in Axum applications using DynamoDB, design handlers so that all code paths involving a given operation take approximately the same amount of time. This includes avoiding early returns based on item existence and ensuring cryptographic operations run in constant time.

Below is a concrete Axum handler example that first retrieves an item from DynamoDB by partition key, then performs constant-time verification. The key remediation is to always perform a comparable amount of work regardless of whether the item exists, and to avoid branching on sensitive conditions that depend on database results.

use aws_sdk_dynamodb::Client;
use axum::{routing::post, Router};
use std::net::SocketAddr;

async fn login_handler(
    client: Client,
    payload: LoginPayload,
) -> Result<impl Into<axum::response::Response>, (axum::http::StatusCode, String)> {
    // Always fetch the record to keep timing consistent
    let result = client
        .get_item()
        .table_name("users")
        .key("username", aws_sdk_dynamodb::types::AttributeValue::S(payload.username.clone()).into())
        .send()
        .await;

    let item = match result {
        Ok(output) => output.item.ok_or((axum::http::StatusCode::UNAUTHORIZED, "Invalid credentials".to_string()))?,
        Err(_) => // Return a generic error and perform dummy work to keep timing similar
        {
            // Perform a minimal dummy operation to consume comparable time
            let _ = client.list_tables().limit(1).send().await;
            return Err((axum::http::StatusCode::UNAUTHORIZED, "Invalid credentials".to_string()));
        }
    };

    // Extract stored hash and salt from the item (constant-time comparison later)
    let stored_hash = item.get("password_hash").and_then(|v| v.as_s().ok()).ok_or_else(|| {
        (axum::http::StatusCode::INTERNAL_SERVER_ERROR, "Malformed user data".to_string())
    })?;

    // Constant-time comparison to avoid timing leaks in verification
    let valid = subtle::ConstantTimeEq::ct_eq(
        &hash_password(&payload.password, &stored_hash),
        &stored_hash.as_str().unwrap().as_bytes(),
    );

    if valid.into() {
        Ok(axum::response::Response::new("OK".into()))
    } else {
        Err((axum::http::StatusCode::UNAUTHORIZED, "Invalid credentials".to_string()))
    }
}

#[derive(serde::Deserialize)]
struct LoginPayload {
    username: String,
    password: String,
}

// Example route builder
pub fn build_router(client: Client) -> Router {
    Router::new().route("/login", post(move |payload| login_handler(client.clone(), payload)))
}

In this example, the handler always performs a get_item call for the given username, ensuring that the request path length and DynamoDB interactions remain similar whether the user exists or not. If the item is missing, the code proceeds to a dummy DynamoDB operation (listing tables with a small limit) to consume comparable time, reducing the risk of timing-based inference. The comparison of credentials uses a constant-time equality check via the subtle crate to avoid branching on secret-dependent data.

For queries that may return variable result sets, enforce a consistent pagination or limit strategy and avoid early loop exits based on sensitive conditions. When using conditional writes, ensure that the decision logic does not introduce observable timing differences by precomputing outcomes where possible.

Using the middleBrick CLI, developers can scan their Axum endpoints to detect potential timing-related findings and verify that remediation aligns with secure coding practices. The dashboard and CI/CD integrations help track security posture over time, while the MCP Server allows rapid checks within development environments.