Credential Stuffing in Axum with Basic Auth

Credential stuffing leverages previously breached username and password pairs to gain unauthorized access. When Basic Auth is used in an Axum web service without additional protections, the protocol itself exposes credentials in every request, which can amplify the impact of stuffing attacks during both interception and brute-force attempts.

Basic Auth transmits credentials as a base64-encoded string in the Authorization header. Although not encrypted by itself, this makes credentials easy to extract if TLS is terminated incorrectly or if logging captures headers inadvertently. In Axum, if routes accepting Basic Auth do not enforce strict transport security or rate limiting, an attacker running a credential stuffing campaign can iterate over leaked credentials with minimal per-request cost.

During a scan, middleBrick’s Authentication check tests whether endpoints accepting credentials enforce sufficient rate controls and whether authentication mechanisms leak information through timing differences or error messages. For Basic Auth in Axum, the presence of a static realm and predictable 401 responses can aid attackers in distinguishing valid usernames, especially when paired with automated tooling that submits many credential pairs in rapid succession.

Input validation checks verify whether Axum applications treat malformed or unexpected Authorization headers safely. Without proper validation, applications might crash or return verbose errors that reveal stack traces or internal paths, assisting an attacker in refining their stuffing list. Data exposure findings can surface if responses differ significantly between valid and invalid credentials, enabling username enumeration as part of the stuffing process.

middleBrick’s BFLA/Privilege Escalation checks examine whether Axum endpoints that rely solely on Basic Auth lack secondary authorization checks. If a user changes their password or resets credentials, an attacker in possession of an old hash may still succeed until the next rotation window, particularly when token or session mechanisms are absent. Inventory Management checks ensure that authentication endpoints are tracked consistently across scans, confirming that no unauthenticated pathways bypass the intended protection.

Securing Basic Auth in Axum requires combining strict transport requirements, careful header parsing, and robust rate controls to mitigate credential stuffing risks. Below are concrete patterns and code examples that demonstrate a hardened approach.

1. Enforce HTTPS and strict header handling

Ensure all routes using Basic Auth are served over TLS and that middleware rejects cleartext HTTP. Parse the Authorization header carefully, validating the scheme and decoding only when appropriate.

use axum::{
    async_trait,
    extract::Request,
    http::{self, header},
    response::Response,
    Extension,
};
use std::convert::Infallible;

async fn validate_https_and_auth(
    request: Request,
    Extension(validator): Extension<Validator>,
) -> Result<Request, (http::StatusCode, String)> {
    // Enforce HTTPS
    if request.uri().scheme() != Some(&http::uri::Scheme::HTTPS) {
        return Err((http::StatusCode::FORBIDDEN, "HTTPS required".into()));
    }

    // Extract and validate Authorization header
    let auth_header = request.headers()
        .get(header::AUTHORIZATION)
        .ok_or_else(|| (http::StatusCode::UNAUTHORIZED, "Missing Authorization header".into()))?;
    let auth_str = auth_header.to_str().map_err(|_| (http::StatusCode::UNAUTHORIZED, "Invalid header encoding".into()))?;
    if !auth_str.starts_with("Basic ") {
        return Err((http::StatusCode::UNAUTHORIZED, "Invalid authentication scheme".into()));
    }

    // Decode credentials safely (example uses base64)
    let decoded = base64::decode(&auth_str[6..]).map_err(|_| (http::StatusCode::UNAUTHORIZED, "Invalid base64".into()))?;
    let credentials = String::from_utf8(decoded).map_err(|_| (http::StatusCode::UNAUTHORIZED, "Invalid UTF-8".into()))?;
    let parts: Vec<&str> = credentials.splitn(2, ':').collect();
    if parts.len() != 2 {
        return Err((http::StatusCode::UNAUTHORIZED, "Invalid credentials format".into()));
    }
    let (username, password) = (parts[0], parts[1]);

    if validator.validate(username, password).await {
        Ok(request)
    } else {
        Err((http::StatusCode::UNAUTHORIZED, "Invalid credentials".into()))
    }
}

#[tokio::main]
async fn main() {
    let validator = Validator::default();
    let app = axum::Router::new()
        .route("/secure", axum::routing::get(secure_handler))
        .layer(axum::Extension(validator))
        .layer(axum::middleware::from_fn(validate_https_and_auth));

    // Bind to TLS-enabled listener in production
    let listener = tokio::net::TcpListener::bind("127.0.0.1:8443").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

struct Validator;
impl Validator {
    async fn validate(&self, username: &str, password: &str) -> bool {
        // Replace with constant-time comparison and secure storage checks
        username == "alice" && password == "correct-horse-battery-staple"
    }
}

2. Add rate limiting and request-cost controls

Apply per-identity or per-IP rate limits to reduce the feasibility of automated stuffing. Even with Basic Auth, limiting attempts slows down bulk trials and increases attacker cost.

use axum::{
    async_trait,
    extract::State,
    http::StatusCode,
    response::IntoResponse,
};
use std::collections::HashMap;
use std::sync::{Arc, Mutex};
use std::time::{Duration, Instant};

#[derive(Clone)]
struct RateLimiter {
    limits: Arc>>>,
    max_requests: usize,
    window: Duration,
}

impl RateLimiter {
    fn new(max_requests: usize, window: Duration) -> Self {
        Self {
            limits: Arc::new(Mutex::new(HashMap::new())),
            max_requests,
            window,
        }
    }

    fn allow(&self, key: &str) -> bool {
        let now = Instant::now();
        let mut limits = self.limits.lock().unwrap();
        let window_start = now - self.window;
        let requests = limits.entry(key.to_string()).or_default();
        requests.retain(|&t| t >= window_start);
        if requests.len() < self.max_requests {
            requests.push(now);
            true
        } else {
            false
        }
    }
}

async fn rate_limited_handler(
    State(limiter): State<RateLimiter>,
    axum::extract::header::Authorization<axum::http::headers::Basic> credential,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let username = credential.map(|b| b.user_id().to_string()).unwrap_or_else(|| "unknown".into());
    let key = format!("auth:{}", username);
    if limiter.allow(&key) {
        Ok("Authenticated")
    } else {
        Err((StatusCode::TOO_MANY_REQUESTS, "Rate limit exceeded".into()))
    }
}

3. Defense in depth: combine with other protections

Use middleware to enforce secure headers, avoid verbose error messages, and ensure that authentication failures are consistent in timing and response body to prevent user enumeration. Regularly rotate credentials and prefer stronger mechanisms where feasible.

middleBrick’s scans can verify that these mitigations are reflected in runtime behavior, checking Authentication, BOLA/IDOR, and Data Exposure findings to ensure no regressions in how credentials are handled in Axum services.