Time Of Check Time Of Use in Buffalo with Dynamodb

Time Of Check Time Of Use (TOCTOU) occurs when the state of a resource changes between a read (check) and a subsequent write (use). In Buffalo, this commonly arises when application logic first reads an item from DynamoDB to verify permissions or state, then uses that decision to perform a write. Because DynamoDB is a remote, eventually consistent store, the item may be modified by another process or actor between the read and the write, even within a very short window. This race condition is especially relevant when using conditional writes, as the condition is evaluated at write time, not at read time, so a check that appeared valid can become stale.

Consider a Buffalo application that implements a booking flow: it reads a DynamoDB item to check remaining seats, decides a seat is available, and then writes a reservation. If another request concurrently consumes the last seat between the read and the write, the conditional write may still succeed depending on how the condition is formulated, leading to overselling. DynamoDB’s conditional writes rely on attribute values at commit time; if your check does not enforce the same constraints atomically, the write can apply based on stale information. This pattern also surfaces in workflows that check ownership or status before updating, where an attacker can manipulate timing to act on outdated check results.

The unauthenticated scan capability of middleBrick can surface endpoints in Buffalo that perform read-then-write patterns against DynamoDB without atomic condition enforcement. For example, an endpoint that first fetches an item to validate a transition (e.g., from draft to published) and then updates based on that check can be probed. MiddleBrick’s BOLA/IDOR and Property Authorization checks may flag endpoints where authorization or state checks are not enforced atomically at the data layer, and its LLM/AI Security probes can detect whether injected prompts inadvertently expose such logic in model-facing endpoints that interact with DynamoDB.

To reduce risk, favor DynamoDB conditional expressions that encode the check and the write as a single atomic operation. Avoid separate read-and-decide steps as the sole gatekeeper for writes. Instead, include all necessary invariants directly in the condition expression so that DynamoDB itself enforces consistency. Where application logic requires pre-checks for UX or complex branching, revalidate all assumptions immediately before the write using version attributes or conditional updates, and treat any conditional check failure as a rejection.

Remediate TOCTOU by using DynamoDB conditional writes that encode the check and the update in a single operation. In Buffalo, this means building update requests with ConditionExpression and ExpressionAttributeValues that capture the invariant you want to enforce. Below are concrete examples for common scenarios.

Example 1: Prevent oversell by reserving the last seat atomically

import (
	"context"
	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/feature/dynamodb/attributevalue"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)

type SeatItem struct {
	ID       string `dynamodbav:"id"`
	EventID  string `dynamodbav:"event_id"`
	Total    int64  `dynamodbav:"total"`
	Reserved int64  `dynamodbav:"reserved"`
}

func reserveSeat(ctx context.Context, svc *dynamodb.Client, eventID string) error {
	_, err := svc.UpdateItem(ctx, &dynamodb.UpdateItemInput{
		TableName: aws.String("Events"),
		Key: map[string]types.AttributeValue{
			"id": &types.AttributeValueMemberS{Value: eventID},
		},
		UpdateExpression: aws.String("ADD reserved :inc SET total = total"), // ensure total exists
		ConditionExpression: aws.String("attribute_not_exists(reserved) OR reserved < total"),
		ExpressionAttributeValues: map[string]types.AttributeValue{
			":inc": &types.AttributeValueMemberN{Value: "1"},
		},
	})
	return err
}

The ConditionExpression ensures the update only applies if the reservation would not exceed total seats, and the ADD operation is atomic on the server side, eliminating the race condition between check and use.

Example 2: Status transition with versioning

import (
	"context"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)

func publishDraft(ctx context.Context, svc *dynamodb.Client, itemID string, expectedVersion int64) error {
	_, err := svc.UpdateItem(ctx, &dynamodb.UpdateItemInput{
		TableName: aws.String("Content"),
		Key: map[string]types.AttributeValue{
			"id": &types.AttributeValueMemberS{Value: itemID},
		},
		UpdateExpression: aws.String("SET #status = :published, version = version + :one"),
		ConditionExpression: aws.String("#status = :draft AND version = :expectedVersion"),
		ExpressionAttributeNames: map[string]string{
			"#status": "status",
			"version": "version",
		},
		ExpressionAttributeValues: map[string]types.AttributeValue{
			":published":    &types.AttributeValueMemberS{Value: "published"},
			":draft":        &types.AttributeValueMemberS{Value: "draft"},
			":expectedVersion": &types.AttributeValueMemberN{Value: itoa(expectedVersion)},
			":one":          &types.AttributeValueMemberN{Value: "1"},
		},
	})
	return err
}

This pattern uses a version attribute to ensure the item has not changed since the last read. If another process updates the status or version, the conditional update fails, and the application can retry or report a conflict.

Example 3: Ownership check combined with update

import (
	"context"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)

type DocumentItem struct {
	ID         string `dynamodbav:"id"`
	OwnerID    string `dynamodbav:"owner_id"`
	Archived   bool   `dynamodbav:"archived"`
}

func archiveIfOwned(ctx context.Context, svc *dynamodb.Client, itemID string, userID string) error {
	_, err := svc.UpdateItem(ctx, &dynamodb.UpdateItemInput{
		TableName: aws.String("Documents"),
		Key: map[string]types.AttributeValue{
			"id": &types.AttributeValueMemberS{Value: itemID},
		},
		UpdateExpression: aws.String("SET archived = :true"),
		ConditionExpression: aws.String("owner_id = :uid AND archived = :false"),
		ExpressionAttributeValues: map[string]types.AttributeValue{
			":uid":  &types.AttributeValueMemberS{Value: userID},
			":true": &types.AttributeValueMemberBool{Value: true},
			":false": &types.AttributeValueMemberBool{Value: false},
		},
	})
	return err
}

By embedding ownership and state checks into the ConditionExpression, you ensure the update is atomic and TOCTOU is avoided. middleBrick’s scans can help identify endpoints where such patterns are missing by correlating runtime behavior with the OpenAPI spec and flagging authorization or state inconsistencies.