Time Of Check Time Of Use in Fiber with Dynamodb

Time Of Check Time Of Use (TOCTOU) occurs when the state of a resource is checked before use, but the resource changes between the check and the use. In a Fiber application that uses DynamoDB, this commonly arises when authorization or existence checks are performed using one request, and a subsequent request acts on the result without re-validating the underlying data. Because DynamoDB is a managed NoSQL service, the effective "check" and the "use" may span multiple service calls, network hops, and eventual consistency windows, increasing the window for TOCTOU conditions.

Consider a typical pattern: an endpoint retrieves an item (e.g., a resource or a user record) and verifies ownership or permissions, then passes the item identifier to another function that performs a write. If the item is mutated or deleted between the read and the write, or if the permissions change, the later use may operate on stale assumptions. In Fiber, this can happen across handler functions or middleware layers where a prior handler fetched an item and stored metadata in context, and a downstream handler performs a DynamoDB operation based on that cached context without repeating validation.

With DynamoDB, eventual consistency can exacerbate TOCTOU risks. A read with consistent reads returns the latest committed data, but many applications use strongly consistent reads only where necessary for performance or cost. If a check uses eventual consistency and a later write targets the same item, the check may not reflect the latest state. Additionally, conditional writes in DynamoDB help enforce constraints, but they must be designed carefully; missing or incorrect condition expressions can leave gaps where a stale check permits an invalid write.

Another scenario involves identity-based checks. An endpoint might verify that a resource belongs to a user by querying DynamoDB for the resource and checking the user ID. If the authorization check is separate from the mutation, and the user’s permissions or the resource’s ownership changes between the check and the write, a privileged operation could be incorrectly allowed. In distributed systems, this is often observed in workflows where a task queue processes jobs based on earlier metadata that no longer matches the current state stored in DynamoDB.

To mitigate in Fiber, design handlers to perform authorization and validation as close as possible to the point of use, and prefer strongly consistent reads when correctness is critical. Use DynamoDB conditional expressions to enforce invariants at write time, making the operation fail if the assumed state no longer holds. Avoid caching sensitive authorization decisions across requests without re-verifying against the source of truth. Tools like middleBrick can help by scanning your endpoints for authorization and validation issues, including patterns that may lead to TOCTOU, and by mapping findings to frameworks such as OWASP API Top 10 and providing remediation guidance.

Remediation centers on ensuring that checks and uses are tightly coupled and enforced at the data layer. In Fiber, prefer a single handler flow or transaction-like patterns where the read and write are combined or protected by conditional writes. Below are concrete code examples using the AWS SDK for Go with Fiber, demonstrating safe patterns.

1. Combine check and write with a conditional update

Instead of reading to check ownership and then writing, use a conditional update in DynamoDB so that the write only succeeds if the condition matches. This eliminates the window between check and use.

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

func updateResourceHandler(c *fiber.Ctx) error {
    client := dynamodb.NewFromConfig(aws.Config{})
    id := c.Params("id")
    var reqBody struct {
        Owner string `json:"owner"`
        Value string `json:"value"`
    }
    if err := c.BodyParser(&reqBody); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid payload"})
    }

    _, err := client.UpdateItem(c.Context(), &dynamodb.UpdateItemInput{
        TableName: aws.String("Resources"),
        Key: map[string]types.AttributeValue{
            "ID": &types.AttributeValueMemberS{Value: id},
        },
        UpdateExpression: aws.String("set #val = :v"),
        ConditionExpression: aws.String("owner = :owner"),
        ExpressionAttributeNames: map[string]string{
            "#val": "value",
        },
        ExpressionAttributeValues: map[string]types.AttributeValue{
            ":v": &types.AttributeValueMemberS{Value: reqBody.Value},
            ":owner": &types.AttributeValueMemberS{Value: reqBody.Owner},
        },
    })
    if err != nil {
        // Conditional check failed — the item does not match the expected state
        return c.Status(fiber.StatusForbidden).JSON(fiber.Map{"error": "condition failed, resource may have been modified"})
    }
    return c.JSON(fiber.Map{"status": "ok"})
}

2. Use strongly consistent reads when validating state before write

If you must perform a separate read, use a strongly consistent read and perform the write in the same request where possible. For operations that require a read-then-write pattern, consider using DynamoDB transactions to ensure isolation.

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

func safeTransferHandler(c *fiber.Ctx) error {
    client := dynamodb.NewFromConfig(aws.Config{})
    type TransferRequest struct {
        ResourceID string `json:"resource_id"`
        FromUser   string `json:"from"`
        ToUser     string `json:"to"`
    }
    var req TransferRequest
    if err := c.BodyParser(&req); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid payload"})
    }

    // Strongly consistent read to verify current ownership
    out, err := client.GetItem(c.Context(), &dynamodb.GetItemInput{
        TableName:                 aws.String("Resources"),
        Key:                       map[string]types.AttributeValue{"ID": &types.AttributeValueMemberS{Value: req.ResourceID}},
        ConsistentRead:            aws.Bool(true),
    })
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "failed to read resource"})
    }
    if out.Item == nil {
        return c.Status(fiber.StatusNotFound).JSON(fiber.Map{"error": "resource not found"})
    }
    ownerAttr, ok := out.Item["owner"]
    if !ok {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "missing owner attribute"})
    }
    if ownerAttr.ToString() != req.FromUser {
        return c.Status(fiber.StatusForbidden).JSON(fiber.Map{"error": "not authorized"})
    }

    // Perform the update, optionally with a condition to ensure state hasn't changed
    _, err = client.UpdateItem(c.Context(), &dynamodb.UpdateItemInput{
        TableName: aws.String("Resources"),
        Key: map[string]types.AttributeValue{
            "ID": &types.AttributeValueMemberS{Value: req.ResourceID},
        },
        UpdateExpression: aws.String("set owner = :to"),
        ConditionExpression: aws.String("owner = :from"),
        ExpressionAttributeValues: map[string]types.AttributeValue{
            ":to":   &types.AttributeValueMemberS{Value: req.ToUser},
            ":from": &types.AttributeValueMemberS{Value: req.FromUser},
        },
    })
    if err != nil {
        return c.Status(fiber.StatusConflict).JSON(fiber.Map{"error": "update condition failed, resource was modified concurrently"})
    }
    return c.JSON(fiber.Map{"status": "transferred"})
}

3. Leverage DynamoDB transactions for multi-step workflows

When a workflow requires multiple checks or updates, use a transaction to ensure atomicity and avoid TOCTOU across steps.

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

func atomicUpdateHandler(c *fiber.Ctx) error {
    client := dynamodb.NewFromConfig(aws.Config{})
    id := c.Params("id")
    var req struct {
        ExpectedState string `json:"expected_state"`
        NewState      string `json:"new_state"`
    }
    if err := c.BodyParser(&req); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid payload"})
    }

    _, err := client.TransactWriteItems(c.Context(), &dynamodb.TransactWriteItemsInput{
        TransactItems: []types.TransactWriteItem{
            {
                Update: &types.Update{
                    Table: aws.String("Resources"),
                    Key: map[string]types.AttributeValue{
                        "ID": &types.AttributeValueMemberS{Value: id},
                    },
                    UpdateExpression: aws.String("set state = :new"),
                    ConditionExpression: aws.String("state = :expected"),
                    ExpressionAttributeValues: map[string]types.AttributeValue{
                        ":new":    &types.AttributeValueMemberS{Value: req.NewState},
                        ":expected": &types.AttributeValueMemberS{Value: req.ExpectedState},
                    },
                },
            },
        },
    })
    if err != nil {
        return c.Status(fiber.StatusConflict).JSON(fiber.Map{"error": "transaction condition failed, TOCTOU risk mitigated via atomic transaction"})
    }
    return c.JSON(fiber.Map{"status": "ok"})
}

These patterns reduce TOCTOU risk by ensuring checks and writes are performed atomically or with strict conditional guards. For broader protection across your API surface, middleBrick can scan for authorization and validation issues, including TOCTOU-prone patterns, and provide prioritized findings and remediation guidance within minutes.