Injection Flaws in Axum with Jwt Tokens

Injection flaws in an Axum service that uses JWT tokens often arise when token data is mishandled after extraction from the request. Axum does not parse or validate tokens itself; it relies on middleware that places claims into request extensions or headers. If application code then uses those values to construct queries, commands, or dynamic paths without validation, injection becomes possible.

Consider a route that builds a database query using a subject or name claim extracted from a JWT. An attacker who can influence the token—by stealing a signing key, exploiting a weak issuer/audience check, or tricking a user into using a token they control—can inject malicious values into SQL or NoSQL statements. Even when tokens are properly signed, claims such as sub, email, or roles should be treated as untrusted input because token issuance may be outside your control.

Another vector involves path or header injection when token metadata is forwarded to downstream services. If you embed a token’s payload into URLs, filenames, or command arguments, you risk command injection or template injection depending on how the downstream component processes the data. For example, concatenating a JWT subject into a shell command or a log file path without strict allow-lists can lead to unexpected behavior.

Middleware configuration errors can also amplify injection risks. If the JWT validation middleware is placed after routes that perform unsafe parsing, or if it exposes token content via headers that are later used unsafely, the attack surface increases. An attacker may attempt subject injection via token claims, or exploit overly permissive CORS and header handling to probe for injection endpoints.

In the context of LLM security, injection flaws may also appear in prompts or tool descriptions derived from token claims. If a system prompt or tool parameter is built from user-influenced JWT data without sanitization, it may enable prompt injection or unauthorized function calls. middleBrick’s LLM/AI Security checks include active prompt injection testing and system prompt leakage detection, which can surface these risks when JWT data reaches language model interfaces.

Remediation centers on strict validation, type-safe extraction, and avoiding direct use of token claims in sensitive operations. Use a well-maintained JWT library, validate all standard claims, and keep signing keys secure. Never trust token payloads for authorization decisions without additional checks.

Example 1: Safe extraction and typed usage in Axum. This snippet shows how to validate a token and extract claims into a strongly typed struct, then use the data safely without concatenating raw strings into queries.

use axum::extract::Request;
use axum::middleware::Next;
use axum::response::Response;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};
use std::convert::Infallible;

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    email: String,
    roles: Vec,
    exp: usize,
    iss: String,
    aud: String,
}

async fn validate_jwt(token: &str) -> Result {
    let validation = Validation::new(Algorithm::HS256);
    let token_data = decode::(
        token,
        &DecodingKey::from_secret("your-secure-secret".as_ref()),
        &validation,
    )?;
    // Optionally validate iss, aud, and exp explicitly per policy
    Ok(token_data.claims)
}

async fn auth_middleware(
    mut request: Request,
    next: Next,
) -> Result {
    if let Some(auth_header) = request.headers().get("authorization") {
        if let Ok(auth_str) = auth_header.to_str() {
            if let Some(token) = auth_str.strip_prefix("Bearer ") {
                if let Ok(claims) = validate_jwt(token).await {
                    // Store claims safely, e.g., in request extensions
                    request.extensions_mut().insert(claims);
                }
            }
        }
    }
    next.run(request).await
}

Example 2: Using claims safely in handlers. Instead of injecting values into SQL strings, use parameterized queries. This approach prevents injection regardless of token content.

use axum::extract::State;
use serde::Deserialize;
use sqlx::PgPool;

#[derive(Deserialize)]
struct UpdateProfile {
    display_name: String,
}

async fn update_profile(
    State(pool): State,
    claims: Extension,
    body: Json,
) -> Result {
    // Use claims.sub safely as an identifier with parameterized queries
    sqlx::query(
        "UPDATE profiles SET display_name = $1 WHERE user_id = $2",
    )
    .bind(body.display_name.clone())
    .bind(&claims.sub)
    .execute(&pool)
    .await
    .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(Json(serde_json::json!({"status": "ok"})))
}

Example 3: Defense-in-depth measures. Enforce strict issuer and audience validation, short expiration times, and avoid including sensitive or high-value authorization data in claims. Rotate signing keys regularly and store them in a secure secret manager. Apply allow-lists for roles and scopes, and validate permissions server-side rather than relying on token content alone.

When integrating with LLM workflows, sanitize any token-derived data before it reaches prompts or tool schemas. Use allow-lists for values that flow into system instructions or function descriptions, and employ middleBrick’s MCP Server to scan APIs directly from your AI coding assistant for risky patterns that may arise from JWT-derived inputs.