Integrity Failures in Axum with Basic Auth

Basic Authentication over unencrypted channels is a common source of integrity failures in Axum services. When credentials are transmitted as a Base64-encoded string without TLS, an attacker on the network can observe and modify the token in transit. Because Base64 is reversible, the credential material is effectively cleartext; any modification to the header can change the interpreted identity. This directly undermines integrity: the server may act on behalf of a different principal than the one the client intended to represent.

Integrity risks also arise when the server’s authorization logic does not re-validate the decoded identity for each request. In Axum, if the extractor caches the parsed credentials or skips per-route authentication, an attacker who compromises an initial token (for example via client-side storage manipulation) can reuse or escalate it across routes. This maps to BOLA/IDOR patterns where one user can access or modify another user’s resources simply by changing an identifier derived from the Basic Auth identity.

Another integrity failure scenario occurs when the server uses Basic Auth identity to make authorization decisions without a cryptographic binding to the request. For example, if an endpoint embeds a user ID in a URL or JSON body and relies solely on the Basic Auth username to verify ownership, an attacker who can tamper with the request path or body might perform Insecure Direct Object Reference (IDOR). Even if transport integrity is provided externally (e.g., by a load balancer), Axum must still ensure that the authenticated identity matches the intended resource, enforcing checks such as tenant or ownership validation on every operation.

Middleware that deserializes JSON or other payloads can further weaken integrity if it merges user-controlled data with identity-derived claims. In Axum, extractors that combine Basic Auth information with body fields must ensure that the authenticated identity cannot be overridden by user-supplied keys. Without strict separation, an attacker might supply a modified principal in the request body and have it mistakenly trusted, leading to privilege escalation or unauthorized state changes.

Finally, improper error handling can leak integrity-related information. Detailed 401/403 responses that disclose whether a username exists or whether a token was well-formed help attackers iteratively guess valid identities. In Axum, consistent error formats and status code usage reduce this risk, but the underlying issue remains: Basic Auth over unencrypted or loosely guarded channels exposes both authentication and integrity concerns that must be addressed at the application and transport layers alike.

Remediation focuses on enforcing transport security, strict identity validation, and avoiding privilege confusion. Always terminate TLS before requests reach Axum or use a trusted proxy with verified client certificates. Do not rely on Basic Auth over plain HTTP. When using middleware, ensure that the authenticated identity is bound to the request and cannot be overridden by user input.

Below is a minimal Axum example that demonstrates secure handling of Basic Auth with per-request validation and no mutable credential caching:

use axum::{
    async_trait,
    extract::{FromRequest, Request},
    response::IntoResponse,
};
use base64::prelude::*;
use headers::authorization::Basic;
use headers::Authorization;
use std::convert::Infallible;
use std::sync::Arc;

struct AuthenticatedUser {
    subject: String,
    // additional verified claims, e.g., tenant_id
}

#[async_trait]
impl FromRequest<S> for AuthenticatedUser
where
    S: Send + Sync,
{
    type Rejection = (axum::http::StatusCode, &'static str);

    async fn from_request(req: Request, _state: &S) -> Result<Self, Self::Rejection> {
        let authorization = req.headers().get(Authorization::name())
            .and_then(|h| h.to_str().ok())
            .and_then(|s| s.parse().ok())
            .ok_or((axum::http::StatusCode::UNAUTHORIZED, "missing basic auth"))?;

        let credentials = String::from_utf8(BASE64_STANDARD.decode(authorization.password()).map_err(|_| (axum::http::StatusCode::UNAUTHORIZED, "invalid encoding"))?)
            .map_err(|_| (axum::http::StatusCode::UNAUTHORIZED, "invalid credentials"))?;
        let parts: Vec<&str> = credentials.splitn(2, ':').collect();
        if parts.len() != 2 {
            return Err((axum::http::StatusCode::UNAUTHORIZED, "invalid credentials format"));
        }
        let (username, password) = (parts[0], parts[1]);

        // Perform constant-time verification against a secure store
        if verify_credentials(username, password).await {
            // Re-validate authorization on each request; do not cache identity
            Ok(AuthenticatedUser { subject: username.to_string() })
        } else {
            Err((axum::http::StatusCode::UNAUTHORIZED, "invalid credentials"))
        }
    }
}

async fn verify_credentials(username: &str, password: &str) -> bool {
    // Use a constant-time compare and a secure backend
    // Example placeholder: integrate with your identity provider
    true
}

async fn handler(user: AuthenticatedUser) -> impl IntoResponse {
    format!("Authenticated as: {}", user.subject)
}

#[tokio::main]
async fn main() {
    let app = axum::Router::new().route("/me", axum::routing::get(handler)).layer(axum::middleware::from_fn_with_state(
        (),
        |_state, request, next| async move {
            // Enforce HTTPS or proxy headers indicating TLS termination
            next.run(request).await
        },
    ));
}