Logging Monitoring Failures in Axum with Basic Auth

When an Axum service uses HTTP Basic Authentication without structured logging and monitoring of authentication outcomes, security-relevant events are lost or ignored. Basic Auth sends credentials on each request in an Authorization header encoded as base64 (not encrypted). If the server does not log the fact that Basic Auth was presented, whether it was accepted or rejected, and which user identity was derived, you lose visibility into brute-force attempts, credential stuffing, and misuse of privileged accounts.

In practice, a minimal Axum handler that only checks a hardcoded credential and returns 200 or 401 can fail to record critical context: timestamp, client IP, provided username (or that a credential was supplied), whether the password matched, and the resulting authorization outcome. Without these fields, monitoring dashboards show only opaque spikes in 401 counts or silent 200s that may correspond to attacker success. This lack of observability undermines detection of patterns such as rapid sequential failures from a single IP (credential spraying) or infrequent but successful logins from unusual geolocations (account compromise).

Additionally, if logs are emitted but not centrally collected and analyzed, alerts for suspicious patterns cannot fire. For example, repeated Basic Auth failures for a known admin-like username should trigger an incident; without structured logs and a monitoring pipeline, the signal is buried. MiddleBrick’s 12 security checks include Authentication and BOLA/IDOR evaluations; these scans can surface the absence of proper logging by observing whether responses leak information in timing or body content and whether authentication events are observable. Even in unauthenticated scans, missing audit trails are a detectable gap because there is no evidence that failed authentications are recorded for investigation.

Common implementation anti-patterns in Axum that contribute to this problem include using guard filters that short-circuit before logging, omitting fields like request_id or user_id in log lines, and relying solely on framework default panic or error handlers that do not emit structured entries. Because Basic Auth is often used for simplicity in internal services, teams may neglect to instrument the auth layer, assuming that transport encryption (TLS) is sufficient. Encryption protects credentials in transit but does nothing for detection; logging and monitoring are still required to detect misuse, configuration errors, and evolving attacker behaviors.

To secure an Axum service using Basic Auth, implement structured authentication logging and robust credential handling. Always avoid hardcoding credentials in source; prefer runtime configuration or secure stores. Ensure each authentication attempt is recorded with sufficient context to support monitoring and incident response.

Example: structured logging and a verified Basic Auth extractor in Axum using the tower-http crate.

use axum::{routing::get, Router, extract::RequestParts, http::header};
use tower_http::auth::{AuthLayer, Credentials, ParseAuthorization};
use std::net::SocketAddr;
use tracing_subscriber::{layer::SubscriberExt, util::SubscriberInitExt};

#[derive(Debug, Clone)]
struct User {
    username: String,
    role: String,
}

async fn auth_handler(RequestParts<State> mut req: RequestParts<State>) -> Result<User, (StatusCode, String)> {
    // Extract Authorization header
    let auth = req.headers().get(header::AUTHORIZATION)
        .and_then(|v| v.to_str().ok())
        .ok_or_else(|| (StatusCode::UNAUTHORIZED, "Missing Authorization header".to_string()))?;

    if !auth.starts_with("Basic ") {
        return Err((StatusCode::UNAUTHORIZED, "Unsupported authentication scheme".to_string()));
    }
    let token = &auth["Basic ".len()..];
    let decoded = general_purpose::STANDARD.decode(token)
        .map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid base64".to_string()))?;
    let creds = String::from_utf8(decoded)
        .map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid credentials encoding".to_string()))?;
    let parts: Vec<&str> = creds.splitn(2, ':').collect();
    if parts.len() != 2 {
        return Err((StatusCode::UNAUTHORIZED, "Invalid credentials format".to_string()));
    }
    let (username, password) = (parts[0], parts[1]);

    // Replace with secure lookup (e.g., constant-time compare, hashed password store)
    if username == "admin" && password == "correct_password" {
        tracing::info!(
            target: "auth",
            event = "login_success",
            username = %username,
            ip = %req.extract::<axum::extract::ConnectInfo<SocketAddr>>().ip().to_string(),
            user_agent = %req.headers().get(header::USER_AGENT).map(|v| v.to_str().unwrap_or("")).unwrap_or(""),
            "Authentication succeeded"
        );
        Ok(User { username: username.to_string(), role: "admin".to_string() })
    } else {
        tracing::warn!(
            target: "auth",
            event = "login_failure",
            username = %username,
            ip = %req.extract::<axum::extract::ConnectInfo<SocketAddr>>().ip().to_string(),
            "Authentication failed"
        );
        Err((StatusCode::UNAUTHORIZED, "Invalid credentials".to_string()))
    }
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt::init();

    let app = Router::new()
        .route("/secure", get(auth_handler))
        .layer(AuthLayer::new(ParseAuthorization::default()));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    tracing::info!(address = %addr, "Listening");
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

Key remediation points:

• Log both successes and failures with the same structured fields (username, client IP, user-agent, timestamp via the logging framework).
• Use a dedicated target (e.g., "auth") to allow routing logs to monitoring systems and creating alerts on patterns like repeated failures for the same username.
• Prefer hashed password verification over plaintext comparison; in production, store passwords as bcrypt/argon2 hashes and use constant-time comparison where feasible.
• Consider adding request_id extraction to correlate logs across services and support traceability.
• Do not rely on Basic Auth over TLS alone; augment with rate limiting and anomaly detection, which can be monitored through the same logging pipeline.