Password Spraying in Axum with Jwt Tokens

Password spraying is an authentication abuse technique where a small number of common passwords are tried against many accounts. When this pattern is exercised against an Axum application that uses JWT tokens for session management, the interaction between the login endpoint and token issuance becomes a measurable attack surface. Axum is a Rust web framework built on asynchronous handlers, and JWT tokens are commonly issued via a dedicated route such as POST /api/auth/login that validates credentials and returns a signed token.

In this combination, risk arises when rate limiting or account enumeration protections are weak or absent. If the login handler does not enforce per-IP or per-account attempt throttling, an attacker can run a password spray without triggering account lockouts. Because JWT tokens are often issued upon any successful credential match, each guessed password that is correct results in a valid token that can be used for authenticated requests. The absence of multi-factor authentication further increases the likelihood that a discovered password–username pair leads to a live session.

The scanning methodology employed by middleBrick tests unauthenticated endpoints, including the login route, and checks whether responses leak information about valid users and whether tokens are issued on failed attempts. One of the 12 security checks, Authentication, specifically looks for weak controls around credential validation and token issuance. If Axum routes do not uniformly reject bad credentials with the same HTTP status and response shape, attackers can infer valid usernames, reducing the search space for subsequent spray attempts. The presence of JWT tokens also introduces risks around token leakage in logs or client-side storage, which can amplify the impact of a successful spray.

middleBrick’s LLM/AI Security checks do not directly test password spraying, but they help ensure that token-related endpoints do not leak system prompts or enable prompt injection that could expose authentication logic. The scanner’s rate limiting check evaluates whether the API enforces reasonable request throttling, which is a primary control against password spraying. Because JWT tokens often carry claims about authentication context, ensuring that tokens are short-lived and scoped correctly is essential to limit what a sprayed credential can achieve.

Real-world attack patterns such as Credential Stuffing and OWASP API Top 10 #7: Authentication demonstrate why this combination requires attention. Without coordinated defenses, Axum services can be abused to harvest valid credentials and obtain JWT tokens that bypass perimeter protections. Detecting and mitigating this requires consistent error handling, strong rate limiting, and monitoring for repeated low-volume login attempts across many accounts.

Remediation focuses on hardening the login flow and token handling in Axum. You should enforce uniform error responses, apply rate limiting at the route or middleware level, and ensure JWT tokens are issued only after all checks pass. The following examples assume you use jsonwebtoken or a similar crate for signing tokens and tower or axum middleware for throttling.

First, apply per-route rate limiting to reduce the chance of successful spraying. Using tower::limit::rate and tower::limit::KeyedRateLimit allows you to restrict attempts by IP or by a combination of IP and username. Here is a minimal Axum route with rate limiting applied:

use axum::{routing::post, Router};
use tower_http::rate_limit::{RateLimitLayer, RateLimitRequestKey};
use std::time::Duration;

fn app() -> Router {
    Router::new()
        .route("/api/auth/login", post(login))
        .layer(
            RateLimitLayer::new(
                tower::limit::Concurrent::default(),
                tower::limit::Rate::per(Duration::from_secs(60), 30),
            )
            .keyed_by(|req: &axum::http::Request<_>| -> RateLimitRequestKey {
                let username = req.uri().query().unwrap_or("").to_string();
                RateLimitRequestKey::new(format!("login:{}", username))
            }),
        )
}

Second, ensure that login responses do not reveal whether a username exists. Return a consistent 401 with a generic message regardless of credential validity, and issue JWT tokens only when credentials are fully verified:

use axum::{response::IntoResponse, http::StatusCode};
use jsonwebtoken::{encode, Header, EncodingKey};
use serde::{Serialize, Deserialize};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    exp: usize,
    scope: String,
}

async fn login(
    credentials: axum::extract::Json<LoginRequest>
) -> Result<impl IntoResponse, (StatusCode, &'static str)> {
    let creds = credentials.into_inner();
    // Validate against your user store; ensure timing-safe comparison
    if validate_user(&creds.username, &creds.password).await {
        let claims = Claims {
            sub: creds.username,
            exp: (chrono::Utc::now() + chrono::Duration::minutes(15)).timestamp() as usize,
            scope: "read write".to_string(),
        };
        let token = encode(
            &Header::default(),
            &claims,
            &EncodingKey::from_secret(&[0u8; 32]),
        ).map_err(|_| (StatusCode::INTERNAL_SERVER_ERROR, "token_error"))?;
        Ok((StatusCode::OK, token))
    } else {
        // Always return the same status and shape
        Err((StatusCode::UNAUTHORIZED, "invalid credentials"))
    }
}

Third, include token metadata and short lifetimes to reduce the window of usefulness for a sprayed token. Set exp (expiration) to a short duration and consider embedding a jti (JWT ID) to allow revocation checks. For sensitive operations, require re-authentication or step-up verification rather than relying solely on the initial token.

Finally, integrate continuous monitoring by using middleBrick’s Pro plan to enable continuous monitoring for your API. This keeps risk visibility up to date as routes evolve and helps detect abnormal token issuance patterns that may indicate successful spraying. The CLI tool can be used in scripts to verify that your changes reduce the Authentication risk score over time.