Password Spraying in Axum with Mutual Tls

Password spraying is an authentication attack that attempts a small number of common passwords across many accounts to avoid account lockouts. When Axum services are protected only by password checks and expose an HTTP endpoint, spraying can be effective even if the service requires Mutual Transport Layer Security (Mutual Tls). Mutual Tls verifies the client certificate presented during the TLS handshake, but it does not inherently prevent credential-based attacks; it simply moves the boundary: the server still must authenticate the identity implied by the certificate (often via a mapped username or assertion) and then apply password validation.

In an Axum-based API, Mutual Tls is commonly implemented by inspecting the peer certificate and extracting a principal (for example, a CN or SAN) to identify the user or service. If the application then applies a password check using that extracted identity, an attacker who possesses a valid client certificate can still attempt password spraying against that identity. The presence of Mutual Tls may give a false sense of security, because the TLS layer is seen as strong, while the application layer remains weak to spray attempts. Additionally, if certificate validation is not strictly tied to a unique identity or if fallback logic accepts unauthenticated connections, the attack surface expands.

During a black-box scan, middleBrick tests the unauthenticated attack surface and, where possible, validates that rate limiting and authentication controls apply consistently across both TLS and application layers. One relevant check is authentication: does the endpoint enforce strong verification for both certificate and credentials? Another is BOLA/IDOR: can one certificate or identifier access another’s data due to insufficient authorization checks? Password spraying fits into authentication weaknesses when the endpoint does not enforce per-user rate limits or progressive backoff, allowing an attacker to cycle through passwords without triggering lockout or throttling.

Consider an Axum handler that extracts a username from a certificate and then validates a form password. If no account lockout or delay mechanism exists, an attacker with a valid certificate can iterate passwords efficiently. Even with Mutual Tls, the application must treat the certificate-derived identity as a subject, not as proof of credential possession. The combination therefore exposes a gap: transport-layer assurance does not replace robust, credential-aware protections. Controls such as certificate-bound rate limiting, per-subject attempt tracking, and multi-factor mechanisms are necessary to reduce the risk.

Remediation focuses on ensuring that Mutual Tls is treated as one factor in a multi-factor flow and that authorization decisions consider both certificate identity and credential validity. Axum middleware can validate client certificates, extract principals safely, and enforce rate limits per certificate or mapped user. Below are concrete patterns and code examples.

1. Basic Mutual Tls setup with certificate extraction

Use Rustls via Axum’s tower::ServiceBuilder to require client certificates and extract a stable identity. This example maps the certificate’s subject common name (CN) to a user identifier and stores it in request extensions for downstream handlers.

use axum::{routing::get, Router, extract::Extension, http::Request, middleware::Next};
use std::net::SocketAddr;
use std::sync::Arc;
use tokio_rustls::rustls::{ServerConfig, Certificate, PrivateKey};
use tokio_rustls::TlsAcceptor;
use std::convert::Infallible;
use std::collections::HashMap;

// A simple extension to carry the mapped identity.
#[derive(Clone, Debug)]
struct UserIdentity(String);

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

async fn auth_middleware(req: Request<B>, next: Next<B>) -> Result<axum::response::Response, Infallible> {
    // Extract identity placed earlier by a custom certificate validator.
    if let Some(identity) = req.extensions().get::<UserIdentity>() {
        // Attach identity to request extensions for handlers.
        // Continue to next middleware/handler.
        Ok(next.run(req).await)
    } else {
        // Reject requests without a validated identity.
        Ok(axum::response::Response::builder()
            .status(401)
            .body("Unauthorized".into())
            .unwrap())
    }
}

#[tokio::main]
async fn main() {
    // Configure server-side cert and key.
    let certs = vec![Certificate(vec![] /* load PEM bytes */)];
    let key = PrivateKey(vec![] /* load PEM bytes */);
    let mut server_config = ServerConfig::builder()
        .with_safe_defaults()
        .with_no_client_auth()
        .with_single_cert(certs, key)
        .expect("bad server cert");

    // Require client authentication.
    server_config.client_auth_root_subjects = vec![/* acceptable subject filter */];
    let tls_acceptor = TlsAcceptor::from(Arc::new(server_config));

    // Build Axum app with middleware that validates certs and extracts identity.
    let app = Router::new()
        .route("/hello", get(handler))
        .layer(auth_middleware)
        .layer(Extension(HashMap::::new())); // example extension placeholder

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

use std::collections::HashMap;
use std::sync::{Arc, Mutex};
use std::time::{Duration, Instant};

struct RateLimiter {
    limits: HashMap,
    max_attempts: usize,
    window: Duration,
}

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

    fn allow(&mut self, key: &str) -> bool {
        let now = Instant::now();
        let entry = self.limits.entry(key.to_string()).or_insert((0, now));
        if now.duration_since(entry.1) > self.window {
            entry.0 = 1;
            entry.1 = now;
            true
        } else if entry.0 < self.max_attempts {
            entry.0 += 1;
            true
        } else {
            false
        }
    }
}

// Integrate into middleware before handler.
async fn auth_and_rate_middleware(
    req: Request<B>,
    next: Next<B>,
    limiter: Extension<Arc<Mutex<RateLimiter>>>
) -> Result<axum::response::Response, Infallible> {
    if let Some(identity) = req.extensions().get::<UserIdentity>() {
        let mut limiter = limiter.lock().unwrap();
        if limiter.allow(&identity.0) {
            Ok(next.run(req).await)
        } else {
            Ok(axum::response::Response::builder()
                .status(429)
                .body("Too Many Attempts".into())
                .unwrap())
        }
    } else {
        Ok(axum::response::Response::builder()
            .status(401)
            .body("Unauthorized".into())
            .unwrap())
    }
}

async fn password_handler(
    Extension(identity): Extension<UserIdentity>,
    Form(payload): Form<PasswordPayload>,
) -> impl IntoResponse {
    // Verify payload.password against a per-user stored hash.
    if valid_password(&identity.0, &payload.password) {
        // Issue session or token.
        Json(json!({ "status": "authenticated" }))
    } else {
        StatusCode::UNAUTHORIZED.into_response()
    }
}