Credential Stuffing in Axum (Rust)

Credential stuffing is a volume-based attack where attackers use stolen username and password pairs to gain unauthorized access to user accounts. When an API is built with the Rust web framework Axum and does not implement adequate protections, it can become an attractive target for this abuse. Axum is a minimal, type-safe web framework that does not enforce authentication or rate limiting by default. This design encourages developers to add security controls explicitly. In practice, many Axum services rely on simple session cookies or bearer tokens, which may be reused across services. If those services lack robust login protections, attackers can automate credential validation at scale using bot traffic directed at the login endpoint.

Because Axum handles requests asynchronously and routes them through defined extractors, the framework itself does not inherently limit the rate of authentication attempts. Without middleware such as a rate limiter or explicit guard logic, an attacker can submit thousands of login requests per minute from distributed IP addresses. This can be done without triggering defenses if the service does not track failed attempts per user or per IP. In addition, if the API returns distinct responses for missing accounts versus incorrect passwords, it provides valuable feedback to attackers, enabling them to enumerate valid usernames. When Axum endpoints accept JSON bodies with predictable field names like username and password, automated tooling can easily craft payloads that match the expected schema, increasing the efficiency of the credential stuffing campaign.

The risk is further amplified if the service uses weak password policies or allows commonly reused credentials. Attackers often combine credential stuffing with automated password spraying, testing a small number of common passwords across many accounts. In Rust services, developers sometimes disable security features during local development, such as HTTPS or middleware, and may inadvertently deploy these configurations to production. An Axum service exposed directly to the internet without a reverse proxy or gateway may lack network-level protections, making it easier to target with high request volumes. Because Axum does not enforce authentication, it is up to the developer to integrate identity providers or custom guards. If those integrations are incomplete or improperly configured, the API remains vulnerable.

Another contributing factor is the use of session identifiers that are predictable or not rotated after login. If an Axum application issues a session cookie without the HttpOnly, Secure, and SameSite attributes, it can be more easily captured and reused. In a microservice architecture, a compromised session from one service can allow lateral movement across other Axum-based APIs. Logging and monitoring gaps also play a role; without sufficient visibility into authentication patterns, abnormal spikes in login requests may go unnoticed. MiddleBrick’s unauthenticated scan can detect whether an Axum endpoint exposes a login interface without rate limiting or account lockout mechanisms, highlighting the attack surface before real-world abuse occurs.

Securing an Axum application against credential stuffing requires deliberate middleware and handler design. Developers should implement rate limiting at the route level to restrict the number of login attempts per IP or per user identifier. Axum integrates with tower-based crates such as tower-rate or governor to provide this functionality. Below is an example of applying a rate limiter to a login route using tower_http::limit::RateLimitLayer, which restricts requests based on a token bucket algorithm.

use axum::routing::post;
use axum::Router;
use tower_http::limit::RateLimitLayer;
use std::time::Duration;

let app = Router::new()
    .route("/login", post(login_handler))
    .layer(RateLimitLayer::new(10, Duration::from_secs(60))); // 10 requests per minute

async fn login_handler() -> &'static str {
    "login endpoint"
}

To prevent username enumeration, ensure that the login response is consistent regardless of whether the account exists. This can be achieved by using a dummy hash computation when a user is not found. The following example demonstrates a handler that validates credentials without revealing account existence, using constant-time comparison via the subtle crate.

use axum::{
    extract::State,
    response::IntoResponse,
    Json,
};
use subtle::ConstantTimeEq;
use std::sync::Arc;

struct AppState {
    user_store: Arc<UserStore>,
}

async fn login_handler(
    State(state): State<Arc<AppState>>,
    Json(payload): Json<LoginPayload>,
) -> impl IntoResponse {
    let user = state.user_store.get_by_username(&payload.username).await;
    let dummy_password_hash = hash_password(&payload.password); // dummy computation

    match user {
        Some(real_user) => {
            let real_hash = hash_password_real(&real_user.password);
            if real_hash.ct_eq(&dummy_password_hash).unwrap_u8() == 1 {
                // successful login logic
            }
        }
        None => {
            // still run dummy hash to keep timing consistent
        }
    }
    // Return generic response
    ((axum::http::StatusCode::UNAUTHORIZED, "Invalid credentials"))
}

Implementing multi-factor authentication (MFA) adds a strong layer of defense. Even if credentials are compromised, attackers cannot proceed without the second factor. For Rust services, TOTP libraries such as totp_rs can be integrated into the authentication flow. Additionally, enforcing strong password policies and checking new passwords against known breach databases reduces the likelihood of successful stuffing. Developers should also ensure that all routes are served over TLS and that cookies include security attributes to prevent interception and reuse.

Finally, operational practices such as logging failed attempts and setting up alerts help detect ongoing attacks. Using Axum middleware to capture authentication events and forward them to a monitoring system provides visibility without relying on external WAFs. The combination of rate limiting, secure coding patterns, and consistent error handling significantly reduces the risk of credential stuffing in Rust-based Axum services.