Time Of Check Time Of Use in Axum with Dynamodb

Time Of Check Time Of Use (TOCTOU) occurs in Axum when an application checks a condition such as ownership or permissions against Amazon DynamoDB and then uses the result to perform a subsequent write or state change without guaranteeing that the condition still holds. Because DynamoDB is a managed NoSQL service, the window between the read (check) and the write (use) exists even if you use conditional writes, especially when authorization logic lives in application code rather than in fine-grained access controls. In an Axum handler, this commonly happens when you first fetch a resource to validate permissions and later issue a delete or update based on that earlier decision.

Consider a typical pattern: an endpoint receives an item ID and a user ID, performs a GetItem to verify that the item belongs to the user, and then proceeds with a DeleteItem using a key condition or a separate authorization check. An attacker can change the item’s owner between the read and the write, or cause the conditional expression to evaluate differently at runtime, leading to unauthorized modification or deletion. Because DynamoDB does not natively enforce per-request business policies beyond key schema and IAM conditions, the application must ensure the check and use are tightly bound.

With DynamoDB, you can reduce TOCTOU risk by using conditional writes that encode the authorization invariant directly in the request, rather than relying on a prior read. For example, include the user ID as an attribute in the item and enforce it with a condition expression on write. This way, the check and use happen atomically on the server side, closing the race window inherent in a two-step application-level check-then-act flow in Axum.

In Axum, structuring handlers to minimize shared mutable state and to perform authorization as part of the same DynamoDB request is essential. If you must read first, keep the request context immutable and re-validate within the same conditional write. Also prefer strongly consistent reads when the authorization decision must reflect the latest state, though note that strongly consistent reads have higher latency and do not eliminate the need for atomic conditional writes on the write path.

To mitigate TOCTOU in Axum with DynamoDB, encode authorization checks directly into conditional expressions on write operations and avoid separate read-for-authorization patterns where possible. Below are concrete, idiomatic examples using the official AWS SDK for Rust and Axum handlers.

First, define a DynamoDB item model that includes an owner attribute. Include this attribute in key schema or as a sort key to leverage partition key scoping, which reduces the scope of what an attacker can manipulate:

use aws_sdk_dynamodb::types::SdkError;
use serde::{Deserialize, Serialize};

#[derive(Debug, Clone, Serialize, Deserialize)]
struct Item {
    user_id: String,
    item_id: String,
    data: String,
    // owner attribute stored on the item
    owner: String,
}

Second, implement a delete handler that uses a conditional write to ensure only the owner can delete the item, avoiding a prior read for authorization. Use a condition expression that binds the owner to the authenticated user context:

use aws_sdk_dynamodb::Client;
use http::StatusCode;
use tower_http::auth::Authorization;

async fn delete_item(
    client: &Client,
    item: Item,
    auth: Authorization<impl tower_http::auth::AuthorizationAlgorithm>
) -> Result<(), (StatusCode, String)> {
    let user_id = auth.token().as_str(); // authenticated user ID
    if item.owner != user_id {
        return Err((StatusCode::FORBIDDEN, "Unauthorized".into()));
    }
    // Use a condition expression to make the check-and-use atomic
    match client
        .delete_item()
        .table_name("Items")
        .key(&aws_sdk_dynamodb::types::AttributeValue::S(item.item_id.clone()).into())
        .condition_expression("attribute_exists(item_id) AND owner = :uid")
        .expression_attribute_values(
            {
                let mut map = std::collections::HashMap::new();
                map.insert(":uid".to_string(), aws_sdk_dynamodb::types::AttributeValue::S(user_id.to_string()));
                map
            }
        )
        .send()
        .await
    {
        Ok(_) => Ok(()),
        Err(SdkError::ConditionalCheckFailedException(_)) => {
            Err((StatusCode::CONFLICT, "Item may have been modified or deleted".into()))
        }
        Err(e) => Err((StatusCode::INTERNAL_SERVER_ERROR, format!("{:?}", e))),
    }
}

If you must read before writing, re-check invariants inside the same conditional write and avoid using the earlier read result as the sole authorization basis. For updates, include versioning or timestamps to detect mid-air collisions:

async fn update_item(
    client: &Client,
    item_id: String,
    user_id: String,
    new_data: String,
    expected_version: i64,
) -> Result<(), (StatusCode, String)> {
    match client
        .update_item()
        .table_name("Items")
        .key(&aws_sdk_dynamodb::types::AttributeValue::S(item_id.clone()).into())
        .update_expression("SET data = :data, version = version + :inc")
        .condition_expression(
            "owner = :uid AND version = :ver"
        )
        .expression_attribute_values({
            let mut map = std::collections::HashMap::new();
            map.insert(":uid".to_string(), aws_sdk_dynamodb::types::AttributeValue::S(user_id));
            map.insert(":data".to_string(), aws_sdk_dynamodb::types::AttributeValue::S(new_data));
            map.insert(":ver".to_string(), aws_sdk_dynamodb::types::AttributeValue::N(expected_version.to_string()));
            map.insert(":inc".to_string(), aws_sdk_dynamodb::types::AttributeValue::N("1".to_string()));
            map
        })
        .send()
        .await
    {
        Ok(_) => Ok(()),
        Err(SdkError::ConditionalCheckFailedException(_)) => {
            Err((StatusCode::CONFLICT, "Item changed concurrently".into()))
        }
        Err(e) => Err((StatusCode::INTERNAL_SERVER_ERROR, format!("{:?}", e))),
    }
}

Additionally, scope items by user in the key design (e.g., partition key of user_id) so that operations naturally target only the caller’s rows, reducing the impact of any residual TOCTOU risk. Combine these patterns with runtime scans of your API surface using tools that support OpenAPI/Swagger 2.0/3.0/3.1 with full $ref resolution so that you can correlate endpoint behavior with DynamoDB access patterns and prioritize findings by severity.