Pii Leakage in Axum with Basic Auth

Basic Authentication in Axum transmits credentials in an Authorization header encoded with Base64, which is easily reversible. Because Base64 is not encryption, any service that intercepts or logs this header can recover the credentials. When APIs using this scheme also expose personally identifiable information (PII) in responses, the combination creates a clear pathway for PII leakage.

In Axum, handlers often serialize structured data into JSON responses. If middleware or route logic attaches PII such as email addresses, phone numbers, or government IDs to these responses without strict field selection, and the endpoint relies solely on Basic Auth for access control, an attacker with network visibility can obtain both credentials and sensitive data. For example, a compromised or malicious proxy could log request headers while the response body carries PII. Even without compromising the transport, logs that include the Authorization header alongside response data can correlate credentials with user details, violating confidentiality expectations.

Another vector arises when Axum applications reflect or echo parts of the request in responses. If a handler copies the username from the Basic Auth credential into a JSON payload returned to the client, and that payload is stored in logs or browser history, the PII is duplicated across systems with weak linkage protections. MiddleBrick’s unauthenticated scan detects these scenarios by checking whether responses contain patterns resembling PII and whether authentication is limited to weak schemes like Basic Auth. Findings highlight cases where credentials and data coexist in observable flows, emphasizing the need to segregate authentication from data exposure and to apply strict output filtering.

Remediation focuses on replacing Basic Auth with stronger transport-layer protections and selective data exposure. When credentials must be used, they should only traverse encrypted connections, and responses should omit or mask PII unless explicitly required.

First, enforce HTTPS so that credentials and data are encrypted in transit. Use middleware to reject non-TLS requests in production environments. Second, avoid echoing authentication-derived values in response bodies. If you must include user context, use opaque identifiers rather than raw usernames or emails.

The following example shows a secure Axum setup with TLS termination at the edge and a handler that avoids leaking PII in JSON output.

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

#[tokio::main]
async fn main() {
    let app = Router::new().route("/profile", get(profile_handler));

    let listener = tokio::net::TcpListener::bind("0.0.0.0:8443")
        .await
        .unwrap();
    axum::serve(listener, app).await.unwrap();
}

async fn profile_handler() -> String {
    // In production, derive a user ID from authenticated session state
    // rather than from Basic Auth. This avoids echoing credentials.
    r#"{"user_id": "usr_abc123", "email": "[email protected]"}"#.to_string()
}

For environments that still require Basic Auth during migration, apply strict transport rules and avoid returning PII fields directly. The following pattern demonstrates how to reject non-secure schemes while preparing for a full migration to token-based flows.

use axum::http::header;
use axum::{http::Request, middleware::Next, response::Response, Extension, Json};
use std::convert::Infallible;

async fn auth_middleware(
    request: Request,
    next: Next,
) -> Result {
    let authorization = request.headers().get(header::AUTHORIZATION);
    if let Some(value) = authorization {
        if value.to_str().map_or(false, |s| s.starts_with("Basic ")) {
            // Log attempt and reject; replace with session or token validation
            return Ok(Response::builder()
                .status(403)
                .body("Use HTTPS and migrate to stronger auth".into()
                .unwrap());
        }
    }
    next.run(request).await
}

async fn handler() -> String {
    // Return minimal data; avoid echoing credentials
    r#"{"status": "ok"}"#.to_string()
}

// In your router setup:
// let app = Router::new()
//     .layer(Extension(auth_middleware))
//     .route("/safe", get(handler));

These examples illustrate how to reduce the risk of PII leakage by removing direct ties between authentication identifiers and response content, and by prioritizing encrypted channels. MiddleBrick’s scans verify whether endpoints expose credentials in responses and whether data exposure occurs alongside weak authentication, helping teams prioritize remediation.