Security Misconfiguration in Axum with Jwt Tokens

Security misconfiguration in an Axum API that uses JWT tokens commonly arises when token validation is incomplete or applied inconsistently across routes. For example, an Axum application might protect only selected endpoints while leaving administrative or health-check routes unguarded, or it might accept tokens without verifying signature, issuer, audience, or expiration. If middleware is not composed into the router stack for all relevant routes, an attacker can call unprotected paths and bypass intended authorization boundaries.

Another misconfiguration is accepting unsigned tokens (alg: none) or overly permissive algorithms without enforcing a strict allowlist, which enables token manipulation. Hardcoded or weak secrets, missing token revocation checks, and improper handling of token metadata (such as not validating nbf or custom claims) further weaken the security posture. These issues are especially risky when combined with broad CORS rules or verbose error messages that leak validation details, because they can expose whether a given token is valid and assist further exploitation.

In practice, misconfigured Axum services might also fail to scope tokens to required permissions or resources, effectively granting elevated privileges. Because JWTs are often used for authentication and authorization, missing checks can lead to access control flaws that violate the BOLA/IDOR category. middleBrick scans detect such gaps by validating that protected endpoints enforce token verification and that token validation logic is strict and consistent across the application surface.

Remediation focuses on strict token validation, consistent middleware application, and secure defaults. Use a maintained crate such as jsonwebtoken with explicit algorithm and validation settings. Define a validation structure that sets required claims and enforces issuer, audience, and leeway appropriately.

use axum::{routing::get, Router};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation, TokenData};
use serde::{Deserialize, Serialize};
use std::net::SocketAddr;

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    exp: usize,
    iat: usize,
    iss: String,
    aud: String,
    #[serde(flatten)]
    extra: std::collections::HashMap,
}

async fn validate_token(auth_header: &str) -> Result, jsonwebtoken::errors::Error> {
    let token = auth_header
        .strip_prefix("Bearer ")
        .ok_or_else(|| jsonwebtoken::errors::Error::from(jsonwebtoken::errors::ErrorKind::InvalidToken))?;

    let validation = Validation::new(Algorithm::HS256);
    let decoder = DecodingKey::from_secret("YOUR_STRONG_SECRET_KEY".as_ref());

    decode::(
        token,
        &decoder,
        &validation,
    )
}

async fn public_handler() -> &'static str {
    "public endpoint"
}

async fn protected_handler() -> &'static str {
    "protected endpoint"
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/public", get(public_handler))
        .route("/protected", get(protected_handler))
        // Apply token validation middleware to selected routes only; ensure no route is unintentionally left open.
        .layer(
            // Example: integrate your validation logic here (e.g., via from_fn or a custom extractor).
            // axum_extra::extractors::cookie::CookieJar::default()
        );

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

Key remediation steps include:

Enforce a strict allowlist of algorithms (e.g., HS256 or RS256) and reject none (alg: none).
Always validate exp, nbf, iss, and aud claims against expected values.
Apply token validation middleware to all routes that require authorization, and avoid broad exemptions.
Use strong, rotated secrets or private/public key pairs; do not hardcode secrets in source code.
Return generic error messages for invalid tokens to avoid information leakage that could aid attackers.

middleBrick can verify that these controls are present by correlating the OpenAPI spec (including securitySchemes using JWT) with runtime behavior, ensuring protected endpoints require valid tokens and that token validation follows best practices.