Insufficient Logging in Axum with Basic Auth

Insufficient logging in an Axum service that uses HTTP Basic Authentication can weaken visibility into authentication failures and credential misuse. When Basic Auth is implemented without structured, detailed logs, security-relevant events are not reliably recorded, which limits the ability to detect brute-force attempts, credential stuffing, or token reuse.

In Axum, a common pattern is to use middleware or extractors to validate credentials. If the application only logs at a high level (e.g., request received, request succeeded) and omits authentication-specific outcomes, an attacker can probe credentials with minimal risk of detection. For example, if a middleware layer returns 401 or 403 without recording the username, timestamp, source IP, and request path, defenders lose the ability to correlate repeated failures across endpoints or identify automated attacks.

Consider an Axum router where Basic Auth is enforced via an extractor:

use axum::{routing::get, Router};
use std::net::SocketAddr;

async fn handler() -> &'static str {
    "OK"
}

#[tokio::main]
async fn main() {
    let app = Router::new().route("/secure", get(handler));
    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

In this setup, if authentication is handled externally (e.g., by a gateway) or via a custom extractor that does not log failures, the service provides no insight into who attempted to authenticate, when, or from where. This becomes critical during incident response, where lack of logs prevents reconstruction of an attack timeline.

Additionally, insufficient logging can violate compliance expectations tied to authentication events. Frameworks such as OWASP API Security Top 10 highlight the importance of audit trails for authentication and access control. Without logs that include outcome (success/failure), username, and source context, an organization may struggle to meet SOC 2 or GDPR requirements around access monitoring.

To illustrate a more complete approach, consider logging within an extractor or layer that records key details on each authentication attempt. This ensures that both successful and failed logins are captured, enabling detection patterns such as repeated 401s from a single IP or anomalous timing across usernames.

Remediation focuses on ensuring that every authentication decision in Axum is accompanied by structured logging that captures actionable security telemetry. Below is an example of a custom extractor that validates Basic Auth credentials and logs outcomes with relevant context.

use axum::{
    async_trait,
    extract::{self, FromRequest},
    http::{Request, StatusCode},
};
use std::convert::Infallible;
use log::{info, warn};

struct AuthenticatedUser(String);

struct BasicAuthCredentials {
    username: String,
    password: String,
}

struct BasicAuthError;

impl std::fmt::Display for BasicAuthError {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(f, "Invalid credentials")
    }
}

impl std::error::Error for BasicAuthError {}

#[async_trait]
impl<S: Send + Sync> FromRequest<S> for AuthenticatedUser
where
    S: Send + Sync,
{
    type Rejection = (StatusCode, String);

    async fn from_request(req: Request<S>) -> Result<Self, Self::Rejection> {
        let auth_header = match req.headers().get("authorization") {
            Some(h) => h.to_str().map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid header".into()))?,
            None => return Err((StatusCode::UNAUTHORIZED, "Missing authorization header".into())),
        };

        if !auth_header.starts_with("Basic ") {
            return Err((StatusCode::UNAUTHORIZED, "Unsupported auth method".into()));
        }

        let encoded = auth_header.trim_start_matches("Basic ");
        let decoded = match base64::decode(encoded) {
            Ok(d) => d,
            Err(_) => {
                warn!(target: "auth", "Invalid base64 encoding from source_ip:?",);
                return Err((StatusCode::UNAUTHORIZED, "Invalid credentials".into()));
            }
        };

        let parts: Vec<&str> = String::from_utf8_lossy(&decoded).splitn(2, ':').collect();
        if parts.len() != 2 {
            warn!(target: "auth", "Malformed credentials from source_ip:?");
            return Err((StatusCode::UNAUTHORIZED, "Invalid credentials".into()));
        }

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

        // Replace with actual credential validation logic
        if validate_credentials(&username, &password) {
            info!(target: "auth", "successful_login username={} source_ip=?", username);
            Ok(AuthenticatedUser(username))
        } else {
            warn!(target: "auth", "failed_login username={} source_ip=?", username);
            Err((StatusCode::UNAUTHORIZED, "Invalid credentials".into()))
        }
    }
}

fn validate_credentials(username: &str, password: &str) -> bool {
    // In production, validate against a secure store with constant-time checks
    username == "admin" && password == "correct_password"
}

This pattern ensures that both successful and failed authentication attempts are recorded with the username and source context. The use of structured logging fields (e.g., username, source_ip) enables log aggregation systems to generate alerts on repeated failures for the same user or from a single IP address, which is essential for detecting brute-force or credential-stuffing attacks.

Additionally, remediation includes avoiding logging of raw passwords. The example above logs only the username and outcome, preventing accidental exposure of credentials in log stores. For deployments that use API gateways or reverse proxies to handle Basic Auth, ensure that the gateway also forwards relevant auth-failure events to the application log stream to maintain a complete audit trail.

• Question: Can middleBrick detect insufficient logging issues in Axum Basic Auth configurations?

  middleBrick scans unauthenticated attack surfaces and includes checks related to authentication and observability. While it does not inspect internal application logging code, it can identify whether authentication endpoints expose information leakage or missing security headers that often correlate with poor logging practices. Findings include guidance on improving auditability.

• Question: How does structured logging in Axum help with compliance requirements such as SOC 2 and GDPR?

  Structured logs that include timestamp, username, source IP, and authentication outcome provide an audit trail required by many compliance frameworks. This enables organizations to demonstrate who accessed resources, when, and from where, and to investigate incidents effectively. middleBrick’s reports map findings to frameworks like OWASP API Top 10 and SOC 2, helping teams prioritize remediation.