Data Exposure in Axum with Jwt Tokens

When building HTTP services with the Axum web framework in Rust, developers often integrate JSON Web Token (JWT) handling to manage authentication and authorization. If JWTs are not handled carefully, sensitive information can be unintentionally exposed, leading to a Data Exposure finding in a middleBrick scan. This typically occurs when tokens or their embedded claims are logged, reflected in error messages, or transmitted over insecure channels.

Axum does not enforce any specific JWT library; common patterns use crates like jsonwebtoken or jwt-decode. A vulnerability arises when application code logs or echoes the token or its payload. For example, including the raw Authorization header value in access or error logs can expose bearer tokens to log aggregation systems or console outputs that are accessible to unauthorized parties. Similarly, returning the token or detailed authentication errors to the client can leak information about token structure, signing algorithms, or user identities.

Another exposure path involves insufficient transport protections. If an Axum service accepts JWTs over HTTP instead of enforcing HTTPS, tokens can be intercepted in transit. MiddleBrick’s encryption check flags endpoints that do not mandate TLS, because JWTs function as bearer credentials and must never traverse unencrypted networks. Even when HTTPS is used, misconfigured TLS settings or mixed content issues can weaken the protection of token transmission.

Middleware implementations in Axum can inadvertently contribute to exposure. For instance, a custom middleware that captures request metadata for debugging might include the entire header block, including the Authorization header containing the JWT, in structured logs. If these logs are stored or streamed to a monitoring platform, they become a persistent data exposure risk. middleBrick’s Data Encryption check evaluates whether sensitive data could be exposed through logging or insecure transport, and the Inventory Management check helps identify unexpected data flows involving authentication tokens.

Finally, exposure can occur through token side-channels. If an Axum endpoint reveals whether a JWT is malformed or expired in verbose detail, an attacker can infer valid token lifetimes or structure. Detailed error messages that include stack traces or internal paths may also expose application internals when combined with token processing code. By correlating runtime findings with OpenAPI specifications, middleBrick can highlight endpoints where authentication logic intersects with data exposure risks, ensuring that JWT usage aligns with secure design principles.

To remediate Data Exposure risks related to JWTs in Axum, focus on preventing token leakage in logs and ensuring strict transport security. Below are concrete code examples that demonstrate secure handling patterns.

1. Avoid logging raw tokens

Never log the full Authorization header or the token string. Instead, log only necessary metadata, and sanitize sensitive fields.

// Unsafe: logging the raw header
// let auth_header = request.headers().get("authorization");
// tracing::info!(?auth_header, "request received");

// Safe: log presence without the token value
if let Some(auth_header) = request.headers().get("authorization") {
    tracing::info!(auth_present = true, "request received");
} else {
    tracing::info!(auth_present = false, "request received");
}

2. Use HTTPS and enforce secure transport

Ensure all endpoints are served over HTTPS and that tokens are never accepted over HTTP. In Axum, you can enforce this at the router or middleware level.

use axum::routing::get;
use axum::Router;

// Enforce HTTPS by using a reverse proxy or load balancer that terminates TLS.
// Within Axum, you can add a middleware that rejects non-secure requests.
async fn require_secure() -> Result<(), (StatusCode, String)> {
    // In production, check via headers or connection info provided by your host.
    // This is a simplified example.
    if std::env::var("HTTPS") != Ok("true".to_string()) {
        return Err((StatusCode::FORBIDDEN, "HTTPS required".into()));
    }
    Ok(())
}

let app = Router::new()
    .route("/protected", get(|| async { "secure data" }))
    .layer(axum::middleware::from_fn(require_secure));

3. Validate and sanitize error responses

Do not return raw token content or internal details in error responses. Use generic messages and structured error handling.

use axum::{http::StatusCode, response::IntoResponse};
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
struct ErrorResponse {
    error: String,
}

async fn validate_token(token: String) -> Result<(), impl IntoResponse> {
    if token.is_empty() {
        let err = ErrorResponse { error: "invalid_token".to_string() };
        return Err((StatusCode::BAD_REQUEST, Json(err)).into_response());
    }
    // Perform decoding/verification here
    Ok(())
}

4. Secure token storage and parsing

When decoding JWTs, avoid exposing sensitive claims. Use well-maintained crates and do not trust the payload without verification.

use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};

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

fn verify_token(token: &str) -> Result {
    let decoding_key = DecodingKey::from_secret("secret".as_ref());
    let mut validation = Validation::new(Algorithm::HS256);
    validation.validate_exp = true;
    let token_data = decode::(token, &decoding_key, &validation)?;
    Ok(token_data.claims)
}

5. Apply principle of least privilege to token scope

Issue tokens with minimal scopes and lifetimes. In Axum, integrate token validation with authorization logic to ensure that exposed data is limited to what is necessary for the request.