Time Of Check Time Of Use in Actix with Dynamodb

Time-of-check time-of-use (TOCTOU) occurs when the outcome of a security-relevant check depends on state that can change before the action that uses that check executes. In an Actix web service that stores and retrieves data in DynamoDB, this typically arises when authorization or existence checks are performed separately from the data access operation. An attacker can change the underlying item between the check and the use, bypassing intended controls.

Consider an endpoint that first retrieves an item from DynamoDB to verify ownership and then performs a conditional update. If the item is replaced or its attributes (such as an owner ID or version) changed between the read and the write, the Actix handler may operate on an unintended resource. Because DynamoDB is a managed NoSQL store with its own concurrency model, standard assumptions about locking or transactional guarantees across separate calls do not apply. Even an ETag-based conditional check performed in a separate request does not automatically protect the subsequent write if the check and the write are not part of the same atomic operation.

Actix does not provide built-in mechanisms to bind a read to a write in DynamoDB. Each get_item, query, or scan call is an independent request. If the Actix handler chains these calls and enforces authorization only after retrieving data, an attacker who can influence item attributes (e.g., by triggering a background process or exploiting another weakness) may cause the handler to incorrectly deem the item as authorized. The handler then performs a write using a condition expression that may still pass because the item has evolved, or the handler may skip a condition altogether, leading to unauthorized modification or information exposure.

Using the DynamoDB API directly in Actix requires care around request ordering and conditional expressions. For example, a handler that reads an item, checks a status field, and then updates the same item based on that status is vulnerable if the item changes between the read and the update. This pattern is common in workflows where state transitions are managed in application code rather than inside DynamoDB transactions. The read may return a status that is no longer valid by the time the update executes, and conditional writes may be omitted or incorrectly specified, enabling race conditions.

To reduce TOCTOU risk in Actix with DynamoDB, prefer conditional writes that encode all necessary authorization and state checks within a single atomic operation. Use condition expressions that validate both the expected current values and the authorization context, such as comparing a version attribute or a user-owned attribute directly in the update request. Avoid separate read-for-validation patterns unless they are strictly scoped and followed by a conditional write that reasserts the same checks. When possible, leverage DynamoDB transactions to perform read and write steps atomically, ensuring that the item state observed during the read is preserved for the write within the transaction.

For LLM-related endpoints, middleBrick’s scans include checks for unauthenticated LLM endpoint detection and output scanning for PII or API keys. These checks help identify whether model responses might leak sensitive data or whether prompts are exposed, but they do not fix runtime authorization issues such as TOCTOU. Developers must design Actix handlers so that sensitive decisions and state changes are performed atomically with DynamoDB condition expressions or transactions rather than relying on sequential checks.

Remediation centers on using DynamoDB’s conditional writes and transactions to enforce authorization and state checks atomically, removing the window between check and use. Below are concrete Actix examples using the official AWS SDK for Rust.

1. Conditional update without separate read

Instead of reading an item first, perform an update with a condition that encodes ownership and state. This ensures the update only succeeds if the item matches the expected criteria.

use aws_sdk_dynamodb::types::AttributeValue;
use aws_sdk_dynamodb::Client;

async fn update_item_conditionally(client: &Client, table: &str, item_id: &str, expected_owner: &str, new_status: &str) -> Result<(), aws_sdk_dynamodb::Error> {
    client.update_item()
        .table_name(table)
        .key("id", AttributeValue::S(item_id.to_string()))
        .update_expression("set #status = :new_status, last_updated = :now")
        .condition_expression("attribute_exists(#id) and #owner = :expected_owner")
        .expression_attribute_names({
            let mut map = std::collections::HashMap::new();
            map.insert("#id", "id");
            map.insert("#owner", "owner");
            map.insert("#status", "status");
            map
        })
        .expression_attribute_values({
            let mut map = std::collections::HashMap::new();
            map.insert(":new_status", AttributeValue::S(new_status.to_string()));
            map.insert(":expected_owner", AttributeValue::S(expected_owner.to_string()));
            map.insert(":now", AttributeValue::N(chrono::Utc::now().timestamp_millis().to_string()));
            map
        })
        .send()
        .await?;
    Ok(())
}

This pattern removes the read-before-write TOCTOU vector by encoding the ownership check directly in the condition expression.

2. Conditional check within a transaction

If a read is necessary, perform it inside a transaction and then use conditional writes based on the observed values. This keeps the read and write logically bound.

use aws_sdk_dynamodb::types::AttributeValue;
use aws_sdk_dynamodb::Client;

async fn process_in_transaction(client: &Client, table: &str, item_id: &str, expected_status: &str) -> Result<(), aws_sdk_dynamodb::Error> {
    let transaction_items = vec![
        aws_sdk_dynamodb::types::TransactionGet::new()
            .key("id", AttributeValue::S(item_id.to_string()))
            .table_name(table.to_string()),
    ];
    let get_outcome = client.transact_get_items().set_transact_items(Some(transaction_items)).send().await?;

    if let Some(items) = get_outcome.responses {
        if let Some(item) = items.first().and_then(|r| r.item.as_ref()) {
            if let Some(status_val) = item.get("status") {
                if let Some(status) = status_val.as_s() {
                    if status == expected_status {
                        client.update_item()
                            .table_name(table)
                            .key("id", AttributeValue::S(item_id.to_string()))
                            .update_expression("set #status = :new_status")
                            .condition_expression("status = :expected_status")
                            .expression_attribute_names({
                                let mut map = std::collections::HashMap::new();
                                map.insert("#status", "status");
                                map
                            })
                            .expression_attribute_values({
                                let mut map = std::collections::HashMap::new();
                                map.insert(":new_status", AttributeValue::S("processed".to_string()));
                                map.insert(":expected_status", AttributeValue::S(expected_status.to_string()));
                                map
                            })
                            .send()
                            .await?;
                    }
                }
            }
        }
    }
    Ok(())
}

3. Use optimistic locking with a version attribute

Store a version or timestamp attribute and include it in condition expressions on writes. This prevents overwriting changes made by other actors between a read and a write that would otherwise appear valid after the read.

use aws_sdk_dynamodb::types::AttributeValue;
use aws_sdk_dynamodb::Client;

async fn update_with_version(client: &Client, table: &str, item_id: &str, expected_version: i64, new_data: &str) -> Result<(), aws_sdk_dynamodb::Error> {
    client.update_item()
        .table_name(table)
        .key("id", AttributeValue::S(item_id.to_string()))
        .update_expression("set data = :new_data, version = version + :inc")
        .condition_expression("version = :expected_version")
        .expression_attribute_values({
            let mut map = std::collections::HashMap::new();
            map.insert(":new_data", AttributeValue::S(new_data.to_string()));
            map.insert(":expected_version", AttributeValue::N(expected_version.to_string()));
            map.insert(":inc", AttributeValue::N("1".to_string()));
            map
        })
        .send()
        .await?;
    Ok(())
}

These patterns ensure that authorization and state checks are enforced atomically, mitigating TOCTOU risks. middleBrick’s scans can be integrated into your workflow via the CLI (middlebrick scan <url>), the GitHub Action for CI/CD gates, or the MCP Server in your IDE to continuously monitor endpoints for issues including authentication weaknesses that can exacerbate TOCTOU scenarios.