Type Confusion in Axum with Basic Auth

Type confusion in Axum when using Basic Authentication typically arises when the authorization header is parsed into a loosely typed value and later used in a context that expects a more specific type. For example, a handler may extract the credentials via a helper that returns an Option<(String, String)> and then destructure the tuple without enforcing type expectations downstream. If the password field is treated as a generic type (e.g., serde_json::Value or a string that is later cast or compared without validation), an attacker can supply values that cause the runtime interpretation to diverge from the expected structure, leading to logic bypass or incorrect authorization decisions.

Consider an endpoint that guards access using Basic Auth and then performs a role check against a parsed claims structure. If the role is deserialized from user-controlled data without strict type enforcement, an attacker may supply a malformed or unexpected type for the role (e.g., an array instead of a string) and the application may incorrectly treat that as valid, inadvertently granting elevated access. This becomes more likely when the handler uses generic deserialization or when the authorization layer does not enforce strict schema validation before type-based branching.

In the context of middleBrick’s security checks, this pattern is flagged because the scan tests unauthenticated endpoints and analyzes OpenAPI specifications alongside runtime behavior. If the spec defines Basic Auth as a required security scheme but the implementation does not enforce strict types for the parsed credentials, the scan can identify a discrepancy between declared authentication and actual runtime expectations. This mismatch increases the risk of authorization flaws such as BOLA/IDOR or privilege escalation, especially when combined with weak input validation around the Authorization header.

Real-world attack patterns like CVE-2023-30861, which involve header-based confusion leading to privilege escalation, illustrate the class of issues that can emerge when type expectations are not enforced. MiddleBrick’s checks for Input Validation, Authorization (BOLA/IDOR), and Unsafe Consumption are designed to surface these risks by correlating spec definitions with runtime findings, ensuring that type-related misconfigurations are surfaced before they can be exploited.

To mitigate type confusion in Axum when using Basic Authentication, enforce strict parsing and typed structures at the point of extraction. Avoid generic or loosely typed containers for credentials and validate the format before use. Below is a concrete, secure implementation using the basic_auth crate and Axum extractors that guarantees type-safe handling of the Authorization header.

use axum::async_trait;
use basic_auth::Credentials;
use std::convert::Infallible;
use axum::extract::{Request, FromRequest};
use axum::http::StatusCode;
use axum::response::IntoResponse;
use tower_http::auth::{AuthLayer, AuthExtractor};

// Define a strongly typed credentials wrapper
#[derive(Debug, Clone)]
struct AuthenticatedUser {
    username: String,
    role: String, // strictly typed role, not a generic value
}

// Custom extractor that parses Basic Auth and enforces type safety
#[axum::async_trait]
impl FromRequest<S> for AuthenticatedUser
where
    S: Send + Sync,
{
    type Rejection = (StatusCode, &'static str);

    async fn from_request(req: Request, state: &S) -> Result<Self, Self::Rejection> {
        let auth = tower_http::auth::Authorization::<Credentials>from_request(req, state)
            .await
            .map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid authorization header"))?;

        let creds = auth.credentials();
        // Validate expected structure — reject malformed or unexpected types
        if creds.password().is_empty() {
            return Err((StatusCode::UNAUTHORIZED, "Missing credentials"));
        }

        // Enforce type expectations: role must be a known value, not a generic type
        let role = determine_role(&creds.username).ok_or_else(|| {
            (StatusCode::FORBIDDEN, "Insufficient privileges or invalid user type")
        })?;

        Ok(AuthenticatedUser {
            username: creds.username().to_string(),
            role,
        })
    }
}

fn determine_role(username: &str) -> Option<String> {
    // In practice, fetch role from a strongly typed source (database, claims, etc.)
    match username {
        "admin" => Some("admin".to_string()),
        "user" => Some("user".to_string()),
        _ => None,
    }
}

// Apply the auth layer with strict type checks
let auth_layer = AuthLayer::new(AuthenticatedUser::class_check());
let app = Router::new()
    .route("/secure", get(secure_handler))
    .layer(auth_layer);

async fn secure_handler(user: AuthExtractor<AuthenticatedUser>) -> impl IntoResponse {
    format!("Authenticated as {} with role: {}", user.username, user.role)
}