Insufficient Logging in Axum with Dynamodb

Insufficient logging in an Axum service that uses DynamoDB as a persistence layer can leave critical security events unrecorded, reducing traceability and delaying incident response. In this stack, requests flow through Axum handlers, interact with a DynamoDB client, and return responses. If logging is incomplete, attackers can probe endpoints without leaving actionable traces.

Specifically, Axum does not automatically capture structured details of each DynamoDB operation. Without explicit logs, you lose visibility into which identity (or unauthenticated source) invoked a given operation, what item keys were accessed, and which conditional check failed. This gap is significant for security checks such as BOLA/IDOR and Property Authorization, where subtle changes in request parameters indicate probing or privilege escalation attempts.

DynamoDB itself does not emit application-level logs; it provides request metrics and CloudTrail events at an account level. If Axum does not log request identifiers, item keys, condition-expression results, and error codes, correlation between application behavior and DynamoDB outcomes becomes unreliable. For example, a missing log on a GetItem with a malformed key may hide an enumeration attack. Similarly, unlogged UpdateItem conditional check failures can mask unauthorized modification attempts, especially when combined with misconfigured IAM policies.

The absence of structured logs also weakens compliance mappings. Controls such as OWASP API Top 10 A03:2023 (Injection) and A07:2021 (Identification and Authentication Failures) rely on audit trails to verify that authorization decisions are recorded. Without logs that include user context (or absence thereof), request ID tracing, and DynamoDB response metadata, audits cannot verify whether access was appropriately denied or granted.

In a middleBrick scan, insufficient logging often surfaces under Data Exposure and Inventory Management checks, where missing observability increases the risk of undetected data leakage. Because the scan tests unauthenticated surfaces, it can detect endpoints that do not log failures or sensitive paths, highlighting the need for explicit instrumentation in Axum handlers and DynamoDB client interactions.

To address this, ensure each Axum route that performs DynamoDB operations emits structured logs containing at minimum: request ID, method, path, principal or anon indicator, DynamoDB operation and table name, key identifiers (masked if sensitive), condition-expression outcomes, and application-level error codes. This approach aligns with the need for traceability and supports effective remediation guidance when findings are mapped to frameworks such as PCI-DSS and SOC2.

Remediation centers on instrumenting Axum handlers and wrapping DynamoDB calls to emit consistent, structured logs. Use the tracing ecosystem in Rust to propagate request-scoped context and ensure logs include security-relevant fields without exposing secrets.

First, define a logging layer that attaches a request ID and principal status to each incoming request. Then wrap DynamoDB operations to log key parameters and outcomes. Below are concrete, idiomatic examples for an Axum service using the AWS SDK for Rust (aws-sdk-dynamodb).

// Cargo.toml dependencies
// aws-sdk-dynamodb = "0.28"
// tracing = "0.1"
// tracing-subscriber = "0.3"
// axum = "0.7"
// tower-http = { version = "0.5", features = ["trace"] }

use axum::{routing::get, Router};
use aws_sdk_dynamodb::{Client as DynDbClient, types::AttributeValue};
use std::net::SocketAddr;
use tracing::{info, error, instrument};

#[derive(Debug, Clone)]
struct AppState {
    dynamodb: DynDbClient,
    table_name: String,
}

#[instrument(skip(state))]
async fn get_item_handler(
    state: axum::extract::State<AppState>,
    axum::extract::Path(key): axum::extract::Path {
            let item_exists = output.item().is_some();
            info!(
                request_id = %request_id,
                operation = "GetItem",
                table = %state.table_name,
                key = %key,
                item_exists = item_exists,
                "DynamoDB operation completed"
            );
            if item_exists {
                Ok(axum::response::Response::new("OK".into()))
            } else {
                Err((axum::http::StatusCode::NOT_FOUND, "Not found".into()))
            }
        }
        Err(e) => {
            error!(
                request_id = %request_id,
                operation = "GetItem",
                table = %state.table_name,
                key = %key,
                error = %e,
                "DynamoDB GetItem failed"
            );
            Err((axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))
        }
    }
}

#[instrument(skip(state))
async fn update_item_handler(
    state: axum::extract::State<AppState>,
    axum::extract::Json(payload): axum::extract::Json<UpdatePayload>,
) -> Result<axum::response::Response, (axum::http::StatusCode, String)> {
    let request_id = uuid::Uuid::new_v4().to_string();
    info!(
        request_id = %request_id,
        method = "PATCH",
        path = "/items/{id}",
        operation = "UpdateItem",
        table = %state.table_name,
        key = %payload.id,
        "incoming request"
    );

    let update_expr = "SET #status = :s WHERE id = :id";
    let expression_attr_names = std::iter::once(("#status", AttributeValue::S("status".into()))).collect();
    let expression_attr_values = std::iter::once((":s", AttributeValue::S(payload.status.clone()))).collect();

    let response = state.dynamodb.update_item()
        .table_name(&state.table_name)
        .key("id", AttributeValue::S(payload.id.clone()))
        .update_expression(update_expr)
        .set_expression_attribute_names(Some(expression_attr_names))
        .set_expression_attribute_values(Some(expression_attr_values))
        .condition_expression("attribute_exists(id)")
        .send()
        .await;

    match response {
        Ok(_) => {
            info!(
                request_id = %request_id,
                operation = "UpdateItem",
                table = %state.table_name,
                key = %payload.id,
                "DynamoDB update succeeded"
            );
            Ok(axum::response::Response::new("Updated".into()))
        }
        Err(e) => {
            error!(
                request_id = %request_id,
                operation = "UpdateItem",
                table = %state.table_name,
                key = %payload.id,
                error = %e,
                "DynamoDB UpdateItem failed"
            );
            Err((axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))
        }
    }
}

#[tokio::main]
async fn main() -> std::io::Result<()> {
    tracing_subscriber::fmt::init();
    let config = aws_config::load_from_env().await;
    let client = DynDbClient::new(&config);
    let app = Router::new()
        .route("/items/:id", get(get_item_handler))
        .route("/items", axum::routing::patch(update_item_handler))
        .with_state(AppState { dynamodb: client, table_name: "Items".into() });

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

Key points in this remediation:

• Each handler logs the request ID, HTTP method, path, operation, table name, and key identifiers.
• Outcomes are explicitly logged: item existence for GetItem, success/failure for UpdateItem, with error details at ERROR level.
• Condition expressions and attribute names/values are captured in logs where appropriate to support auditability without leaking sensitive data (mask as needed).
• Instrumentation and structured logs align with observability requirements that help satisfy compliance mappings for OWASP API Top 10 and SOC2 audit trails.

In a middleBrick scan, these logs improve visibility under Data Exposure and Inventory Management checks by ensuring that access attempts, failures, and anomalies are recorded for analysis and remediation guidance.