Unicode Normalization in Fiber with Dynamodb

Unicode normalization inconsistencies between HTTP request handling in Fiber and the string comparison logic used when interacting with Amazon DynamoDB can create authorization bypass and injection-like conditions. In Fiber, route parameters and headers are often passed directly into DynamoDB query key expressions. If a client sends a Unicode string that is canonically equivalent to an existing primary key but uses a different normalization form (for example, composed vs decomposed), the application may treat them as distinct values at the HTTP layer while DynamoDB stores or indexes them differently depending on how the strings were originally written.

Consider a user registration flow where the user_id path parameter is used as a partition key in a DynamoDB table. A request with /user/café may normalize internally in Fiber to a composed form (café, U+00E9), while an earlier registration used the decomposed form (café). If the query in DynamoDB does not normalize both sides, the application may fail to locate the existing record, leading to duplicate entries or, worse, allow an attacker to register a visually identical identifier and exploit mismatched ownership checks via BOLA/IDOR. This becomes a practical issue when endpoints perform lookups without explicit normalization before constructing the DynamoDB key condition expression.

Another vector arises with attribute-based filtering. An attacker could supply a normalized string in one request and a non-normalized string in another to bypass property authorization checks. Because DynamoDB does not apply Unicode normalization automatically, two logically equal identifiers can map to different byte sequences, causing conditional checks in application code to evaluate inconsistently. This can lead to IDOR when an attacker iterates through permutations of a normalized vs. non-normalized username or email to access another user’s resources. The risk is compounded when the application uses secondary indexes that include string keys without normalization, allowing enumeration across visually identical but distinct representations.

A concrete example involves a DynamoDB query used to retrieve a user profile by email. If the email is stored in normalized form and the incoming request from Fiber is not normalized, the query may return no results. The application may then fall back to creating a new profile or escalating privileges, effectively enabling account takeover or horizontal privilege escalation via crafted Unicode input. The 12 security checks in middleBrick highlight such input validation and authorization gaps by correlating runtime behavior with OpenAPI definitions and detecting missing normalization in string handling paths that involve DynamoDB.

To detect these issues in practice, middleBrick’s input validation and BOLA/IDOR checks examine how strings are passed into DynamoDB operations during black-box scanning. By analyzing unauthenticated attack surfaces, the scanner surfaces inconsistencies between expected authorization boundaries and actual query behavior, especially when endpoint paths or headers feed directly into key expressions. This helps teams identify where Unicode normalization must be enforced to ensure logical equivalence is preserved across the full stack, from HTTP layer to DynamoDB storage and query logic.

Remediation centers on normalizing Unicode strings before using them in DynamoDB key expressions or attribute comparisons in Fiber applications. Use a deterministic normalization form, typically NFC or NFD, and apply it consistently for both writes and reads. In Go, the golang.org/x/text/unicode/norm package provides standard normalization utilities that can be integrated into Fiber middleware or handler logic to ensure all identifiers are normalized before interacting with DynamoDB.

Example: Normalizing a user ID from a route parameter before building a DynamoDB key condition.

import (
    "github.com/gofiber/fiber/v2"
    "golang.org/x/text/unicode/norm"
)

func GetProfile(c *fiber.Ctx) error {
    userID := c.Params("user_id")
    normalized := norm.NFC.String(userID)

    // Assuming a DynamoDB client named dynamoClient and a table name
    result, err := dynamoClient.GetItem(&dynamodb.GetItemInput{
        TableName: aws.String("Users"),
        Key: map[string]types.AttributeValue{
            "user_id": &types.AttributeValueMemberS{Value: normalized},
        },
    })
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    if result.Item == nil {
        return c.Status(fiber.StatusNotFound).JSON(fiber.Map{"error": "not found"})
    }
    return c.JSON(result.Item)
}

Example: Applying normalization when querying a DynamoDB table for emails in login flows.

func Login(c *fiber.Ctx) error {
    email := c.FormValue("email")
    normalizedEmail := norm.NFC.String(email)

    // Query the Users table where email is the partition key
    result, err := dynamoClient.Query(&dynamodb.QueryInput{
        TableName: aws.String("Users"),
        KeyConditionExpression: aws.String("email = :email"),
        ExpressionAttributeValues: map[string]types.AttributeValue{
            ":email": &types.AttributeValueMemberS{Value: normalizedEmail},
        },
    })
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    if len(result.Items) == 0 {
        return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid credentials"})
    }
    // Proceed with session creation
    return c.JSON(result.Items[0])
}

For continuous protection, integrate normalization into a Fiber middleware so that all incoming string parameters destined for DynamoDB are normalized before reaching handlers. This ensures consistent treatment across the application and reduces the risk of bypassing authorization checks due to encoding differences. middleBrick’s Pro plan supports continuous monitoring for such input validation issues, and its GitHub Action can flag missing normalization in CI/CD pipelines before deployment.