Time Of Check Time Of Use in Fastapi with Dynamodb

Time of Check to Time of Use (TOCTOU) occurs when a system checks a condition (such as ownership or permissions) and then relies on that condition when acting shortly after, but the state can change between the check and the use. In a Fastapi application that uses DynamoDB, this commonly surfaces in workflows where authorization is verified with a read call, and a subsequent write call assumes the same authorization context without re-verifying it.

Consider an endpoint that first retrieves an item from DynamoDB to confirm the item’s owner matches the requesting user, then uses the item’s identifier to perform a delete or update. If the ownership check and the delete/update are separate operations, an attacker who can modify the item between the read and write can exploit the race condition. For example, a user might read item X and confirm it belongs to them, but before the delete request completes, an attacker could have updated item X to belong to another user. If the delete proceeds based on the earlier check, the attacker could cause unintended data modification or deletion.

DynamoDB’s consistency options influence the risk. Eventually consistent reads may return stale data for the check, widening the window for inconsistency between the check and the use. Even strongly consistent reads do not prevent TOCTOU if the application logic does not enforce permissions at the point of use. A common anti-pattern in Fastapi is to perform an explicit get for authorization and then call delete with only the item key, trusting that the key still maps to the same resource and permissions. This pattern is vulnerable because the mapping and permissions can change between the get and the delete.

Additionally, conditional writes in DynamoDB can mitigate some forms of TOCTOU by encoding expected state directly in the write request. However, if the conditional expression only checks for existence or a version number without validating ownership or other authorization attributes at write time, the vulnerability persists. An attacker who can manipulate the item between the check and the conditional write may still force an unauthorized operation if the condition does not include the current authorization context (such as the user ID).

In Fastapi, the interaction with DynamoDB SDK clients also matters. If the application reuses a low-level client and performs multiple service calls without tightening authorization checks, the surface for TOCTOU grows. Real-world scenarios include workflows where an item is marked as pending by one service, then acted upon by another service or callback, without re-evaluating permissions at the callback boundary.

To address TOCTOU in Fastapi with DynamoDB, enforce authorization and constraints at the point of use rather than relying on earlier checks. Prefer conditional writes that encode both the state change and the authorization claim, and avoid separate read-for-authorization followed by write-by-key patterns.

Example: Instead of reading an item to verify ownership and then deleting by key, include the ownership condition in a conditional delete request. This ensures the write fails if the ownership has changed.

import boto3
from fastapi import FastAPI, HTTPException, Depends
from pydantic import BaseModel

app = FastAPI()
dynamodb = boto3.resource("dynamodb", region_name="us-east-1")
table = dynamodb.Table("Items")

class Item(BaseModel):
    user_id: str
    item_id: str
    # other fields

@app.delete("/items/{item_id}")
def delete_item(item_id: str, user_id: str):
    response = table.delete_item(
        Key={"item_id": item_id},
        ConditionExpression="user_id = :uid",
        ExpressionAttributeValues={":uid": user_id},
    )
    # If ConditionCheckFailedException is raised, Fastapi will return 409
    return {"message": "deleted"}

This pattern moves the authorization check into DynamoDB by requiring that the user_id in the item matches the requesting user at the moment of deletion. If the item’s user_id has been changed by another process, the conditional write fails, preventing unauthorized deletion.

For updates, use conditional expressions that check ownership and expected state. For example, allow an update only if the current owner matches the caller and a version or status is as expected:

class UpdateItem(BaseModel):
    item_id: str
    user_id: str
    status: str
    new_value: str

def update_item(payload: UpdateItem):
    response = table.update_item(
        Key={"item_id": payload.item_id},
        UpdateExpression="SET #val = :newval, status = :newstatus",
        ConditionExpression="user_id = :uid AND status = :expected_status",
        ExpressionAttributeNames="#val": "value"},
        ExpressionAttributeValues={
            ":uid": payload.user_id,
            ":newval": payload.new_value,
            ":newstatus": payload.status,
            ":expected_status": "active",
        },
    )
    return response

Ensure that the item_id is not user-controlled in a way that allows horizontal privilege escalation (e.g., guessing other users’ item IDs). Combine this with ownership checks in the condition to ensure the requester is the current owner. If you must first read the item for business logic, re-validate permissions immediately before the write using the same conditional expression, and handle ConditionalCheckFailedException as an authorization failure.

Other practical steps include using strongly consistent reads for critical authorization checks when necessary, though this does not replace conditional writes. Design endpoints so that the item identifier does not leak across users in a predictable way, or map identifiers to tenant identifiers and include tenant/user conditions on every write. Monitor failed conditional writes to detect potential abuse patterns.