Unicode Normalization in Axum with Dynamodb

Unicode normalization inconsistencies between an Axum web framework layer and Amazon DynamoDB can lead to authentication bypass, IDOR, and data exposure. In Rust web services built with Axum, user-controlled strings such as usernames, identifiers, or keys are often normalized (or not) before being stored in or retrieved from DynamoDB. If normalization differs between the application and the database, the same logical identifier can map to multiple representations. This mismatch allows attackers to supply a specially crafted Unicode string that bypasses expected equality checks and matches a different stored record.

For example, a user registers with a normalized username, but the service performs a different normalization step on login. An attacker can provide a decomposed form (using combining characters) that normalizes to the same logical string but compares differently at the application layer, potentially authenticating as another user if checks are not consistently applied. In DynamoDB, string comparisons are binary and case-sensitive unless explicit normalization is enforced in the application. This can lead to BOLA/IDOR when record keys are derived from user identifiers without canonical normalization, enabling horizontal privilege escalation across users who share equivalent logical identifiers.

Input validation issues compound the risk. If Axum endpoints accept unvalidated Unicode input that is later used to construct DynamoDB keys or query conditions, attackers can exploit normalization variants to access or enumerate resources they should not see. The interplay of normalization and case sensitivity can also affect secondary indexes, such as Global Secondary Indexes (GSI), where sort key normalization mismatches may return unintended items. This is particularly dangerous when authorization checks assume uniqueness that does not hold across Unicode representations. Proper normalization before constructing request parameters for DynamoDB ensures consistent storage and retrieval, reducing the attack surface across authentication, authorization, and data access paths.

To mitigate Unicode normalization risks in an Axum service that uses DynamoDB, normalize all user-supplied strings to a canonical form before using them as keys, query conditions, or index attributes. Use a well-tested Unicode normalization library such as unicode-normalization in Rust to apply NFC or NFD consistently across your application and DynamoDB interactions. Apply normalization at the boundary where user input enters your Axum handlers and before any DynamoDB operation, ensuring that both storage and retrieval paths use the same normalization form.

Below are concrete Axum handler examples using the AWS SDK for Rust with DynamoDB. The first example shows creating an item with a normalized user identifier as a partition key, and the second shows retrieving an item using the same normalized key. These patterns help ensure consistent key representation and reduce the risk of IDOR or authentication bypass due to mismatched Unicode forms.

use axum::{
    extract::Query,
    response::Json,
};
use aws_sdk_dynamodb::types::AttributeValue;
use unicode_normalization::UnicodeNormalization;

async fn create_user(
    Json(payload): Json,
    client: &aws_sdk_dynamodb::Client,
) -> Result<(), String> {
    // Normalize to NFC to ensure canonical representation
    let normalized_user_id: String = payload.user_id.nfc().collect();
    let item = [
        ("pk", AttributeValue::S(normalized_user_id.clone())),
        ("username", AttributeValue::S(payload.username)),
    ]
    .into_iter()
    .collect();

    client
        .put_item()
        .table_name("Users")
        .set_item(Some(item))
        .send()
        .await
        .map_err(|e| e.to_string())?;

    Ok(())
}

async fn get_user(
    Query(params): Query,
    client: &aws_sdk_dynamodb::Client,
) -> Result>, String> {
    let normalized_user_id: String = params.user_id.nfc().collect();
    let resp = client
        .get_item()
        .table_name("Users")
        .key("pk", AttributeValue::S(normalized_user_id))
        .send()
        .await
        .map_err(|e| e.to_string())?;

    let item = resp.item().ok_or("Not found")?;
    // Deserialize item into UserData as needed
    Ok(Json(Some(deserialize_user(item)?)))
}

For update and query operations, always normalize inputs used in key conditions and attribute values. If you use secondary indexes, ensure that attributes stored in GSIs are also normalized consistently with the base table keys. Additionally, enforce strict input validation to reject or transform unexpected Unicode variants before they reach DynamoDB. Combining canonical normalization with precise key construction in Axum reduces inconsistencies and helps prevent privilege escalation and unauthorized access across equivalent Unicode representations.