Information Disclosure in Axum with Basic Auth

Information Disclosure in Axum when Basic Auth is used typically occurs because the authentication mechanism transmits credentials on each request without additional protections. In an Axum application, routes can be designed to accept incoming HTTP requests and inspect headers for an Authorization header formatted as Basic base64(credentials). If the application does not enforce HTTPS, an attacker on the same network can observe the Base64-encoded string and, because Base64 is reversible, recover the plaintext username and password directly from the header. Even when HTTPS is enforced, misconfiguration or inconsistent route protection can leave some endpoints unguarded, allowing an attacker to probe unauthenticated paths and harvest credentials that are then reused elsewhere.

Another vector specific to Axum involves logging and error handling. If request handlers inadvertently include the Authorization header or the decoded credentials in logs or panic messages, sensitive information can be exposed through log aggregation systems or error pages. MiddleBrick’s unauthenticated scan can detect whether your Axum endpoints expose such information by checking for the presence of credentials in responses and server-side artifacts. For example, a handler that echoes headers for debugging might return the full Authorization header to the client, which is a clear information disclosure. The scanner also tests whether endpoints leak data via verbose error traces that reference authentication state, giving an attacker insights into how credentials are processed internally.

The interplay between OpenAPI spec descriptions and runtime behavior is critical here. If your Axum service publishes an OpenAPI spec claiming that certain routes require security schemes using Basic Auth, but those routes are not actually enforced at runtime, the spec becomes a misleading signal. MiddleBrick’s OpenAPI/Swagger analysis resolves all $ref chains and cross-references spec-defined security requirements with live findings. This means a discrepancy between declared and enforced Basic Auth protection is surfaced as a high-severity finding. Attackers can exploit such gaps by targeting routes they discover in documentation that are incorrectly assumed to be protected, leading to unauthorized access and further data exposure.

To remediate Information Disclosure in Axum when using Basic Auth, enforce HTTPS across all routes, validate and sanitize any authentication-related logging, and ensure that security requirements declared in your OpenAPI spec are consistently applied in code. Below are concrete Axum examples that demonstrate a secure approach.

Enforce HTTPS and validate credentials securely

Use middleware to require TLS and inspect the Authorization header without logging sensitive data. The example below shows a guarded route that decodes Basic credentials only over HTTPS and returns 401 without exposing details.

use axum::{
    async_trait,
    extract::Request,
    http::header::AUTHORIZATION,
    response::IntoResponse,
    routing::get,
    Router,
};
use std::net::SocketAddr;

async fn auth_middleware(
    request: Request,
) -> Result<(), (axum::http::StatusCode, String)> {
    let auth_header = request
        .headers()
        .get(AUTHORIZATION)
        .ok_or((axum::http::StatusCode::UNAUTHORIZED, "Missing Authorization header".to_string()))?;

    let auth_str = auth_header
        .to_str()
        .map_err(|_| (axum::http::StatusCode::UNAUTHORIZED, "Invalid header encoding".to_string()))?;

    if !auth_str.starts_with("Basic ") {
        return Err((axum::http::StatusCode::UNAUTHORIZED, "Unsupported auth scheme".to_string()));
    }

    let encoded = auth_str.trim_start_matches("Basic ");
    // Decode and validate credentials without logging them.
    let decoded = base64::decode(encoded)
        .map_err(|_| (axum::http::StatusCode::UNAUTHORIZED, "Invalid credentials encoding".to_string()))?;
    let credentials = String::from_utf8(decoded)
        .map_err(|_| (axum::http::StatusCode::UNAUTHORIZED, "Invalid credentials format".to_string()))?;
    let parts: Vec<&str> = credentials.splitn(2, ':').collect();
    if parts.len() != 2 {
        return Err((axum::http::StatusCode::UNAUTHORIZED, "Invalid credentials format".to_string()));
    }
    let (user, pass) = (parts[0], parts[1]);
    // Perform validation (e.g., constant-time compare) without printing user/pass.
    if valid_user_pass(user, pass) {
        Ok(())
    } else {
        Err((axum::http::StatusCode::UNAUTHORIZED, "Invalid credentials".to_string()))
    }
}

async fn valid_user_pass(_user: &str, _pass: &str) -> bool {
    // Replace with secure credential verification.
    true
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/secure", get(|| async { "OK" }))
        .layer(axum::middleware::from_fn(auth_middleware));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

OpenAPI spec alignment and CI checks

Ensure your OpenAPI spec accurately reflects which routes require Basic Auth and that your CI pipeline validates this. The following GitHub Action snippet adds MiddleBrick to your workflow to fail builds if security scores drop or if auth-related findings appear on critical routes.

on:
  pull_request:
    branches: [main]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run middleBrick
        uses: middlebjorn/middlebrick-github-action@v1
        with:
          url: 'https://api.example.com/openapi.json'
          threshold: 'B'

By combining runtime enforcement, careful handling of credentials in logs, and automated spec-to-runtime validation, you reduce the risk of Information Disclosure in Axum services using Basic Auth.