Unicode Normalization in Actix with Basic Auth

Unicode normalization attacks exploit different byte representations of equivalent characters. In Actix applications that use HTTP Basic Authentication, this becomes particularly relevant because the Authorization header value is often processed multiple times: first by the web framework to extract credentials, and then by any internal user lookup or comparison logic. If credential comparison is performed without normalizing both the submitted input and the stored canonical form, an attacker can provide a visually identical username or password that fails to match the stored value yet passes an incomplete check due to a different normalization form.

Consider an Actix service that parses the Authorization header using actix_web::http::header::AUTHORIZATION and decodes the Base64 payload into a username and password. If the application stores usernames in NFC (Canonical Composition) but the client submits the same logical string in NFD (Canonical Decomposition), the bytes differ even though they render identically. Without normalization, the comparison may treat these as distinct, leading to authentication bypass logic or inconsistent enforcement of account-based policies. Attack patterns leveraging this include credential confusion, privilege escalation across accounts that should be isolated, and bypassing rate-limiting or auditing tied to a specific identity.

Because middleBrick scans the unauthenticated attack surface, it can detect indicators of normalization inconsistency by observing behavior across variant representations of credentials. Findings may highlight inconsistent handling of Unicode input in authentication paths and map the issue to the Authentication and Input Validation checks. This aligns with the broader OWASP API Top 10 category A07:2021 — Identification and Authentication Failures. Remediation guidance emphasizes canonicalizing usernames and passwords before comparison and ensuring that normalization is applied consistently across storage, parsing, and verification steps.

In an API security report, middleBrick may surface related concerns such as weak input validation or missing property-level authorization when normalization gaps allow logically equivalent but byte-distinct identifiers to be treated differently. Developers should treat the Authorization header as untrusted data, apply normalization (e.g., NFC) before any lookup, and validate that the normalized credential matches the stored form exactly, thereby reducing the risk of bypass via homoglyphs or composed/decomposed sequences.

Secure handling of Basic Authentication in Actix requires explicit decoding, canonical Unicode normalization, and constant-time comparison where feasible. Below is a concrete, syntactically correct example that demonstrates how to implement this in an Actix web handler.

use actix_web::{web, HttpRequest, HttpResponse, Result};
use base64::prelude::*;
use std::collections::HashMap;

/// Normalize a string to NFC using the unicode-normalization crate.
fn normalize_nfc(s: &str) -> String {
    use unicode_normalization::UnicodeNormalization;
    s.nfc().collect()
}

/// Extract and validate Basic Auth credentials with Unicode normalization.
async fn validate_basic_auth(req: &HttpRequest) -> Result<(String, String)> {
    let header = req.headers()
        .get("Authorization")
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("missing authorization header"))?;

    let header_str = header.to_str().map_err(|_| actix_web::error::ErrorUnauthorized("invalid authorization header"))?;
    if !header_str.starts_with("Basic ") {
        return Err(actix_web::error::ErrorUnauthorized("invalid authorization scheme"));
    }

    let encoded = header_str.trim_start_matches("Basic ").trim();
    let decoded_bytes = BASE64_STANDARD.decode(encoded)
        .map_err(|_| actix_web::error::ErrorUnauthorized("invalid base64"))?;
    let decoded_str = String::from_utf8(decoded_bytes)
        .map_err(|_| actix_web::error::ErrorUnauthorized("invalid utf-8"))?;

    // Expected format: username:password
    let parts: Vec<&str> = decoded_str.splitn(2, ':').collect();
    if parts.len() != 2 {
        return Err(actix_web::error::ErrorUnauthorized("malformed credentials"));
    }

    let username = normalize_nfc(parts[0]);
    let password = normalize_nfc(parts[1]);

    // Here you would compare against stored canonical values.
    // For illustration, we accept a hardcoded pair after normalization.
    if username == normalize_nfc("alice") && password == normalize_nfc("secrët") {
        Ok((username, password))
    } else {
        Err(actix_web::error::ErrorUnauthorized("invalid credentials"))
    }
}

/// Example protected route using Basic Auth with normalization.
async fn protected(info: web::Json>, req: HttpRequest) -> Result {
    validate_basic_auth(&req).await?;
    Ok(HttpResponse::Ok().json(info))
}

This pattern ensures that both the submitted and stored usernames and passwords are normalized to a canonical Unicode form before comparison, mitigating risks arising from composed versus decomposed characters. For production use, replace the hardcoded check with a secure lookup against a hashed credential store while preserving normalization on input. middleBrick can help verify that such normalization is consistently applied by testing endpoints with Unicode-variant payloads and reporting deviations in authentication behavior.