Pii Leakage in Axum with Jwt Tokens

In an Axum application that uses JWT tokens for authentication, PII leakage can occur when token payloads include personally identifiable information and those tokens are transmitted or stored insecurely. Axum is a web framework for Rust, and JWT tokens are commonly implemented using crates such as jsonwebtoken. If a developer embeds fields like email, user ID, full name, or other identifiers directly into the JWT claims, the token becomes a potential data exposure vector.

Without proper safeguards, JWTs can be exposed in logs, browser storage, or through insecure transport mechanisms. Even when tokens are signed, the claims are often base64-encoded and not encrypted by default. This means any service or client that intercepts or has access to the token can decode the payload and read the embedded PII. MiddleBrick detects this pattern during black-box scanning by analyzing runtime behavior and OpenAPI specifications, identifying whether tokens expose sensitive data in error messages, reflection endpoints, or debug routes.

Another common issue in Axum setups is the over-fetching of claims. A token may include a broad set of user attributes to simplify authorization logic, inadvertently including sensitive fields that are not required for the operation. When these tokens are passed across microservices or logged for debugging, the PII travels beyond the intended boundaries. The scanner checks whether token validation is consistently applied across all routes and whether middleware is configured to reject tokens with malformed or overly permissive claims, which can lead to unauthorized exposure.

SSRF and external dependency risks also contribute to PII leakage in this context. If an Axum service calls external endpoints using data from JWT claims, such as user location or identifiers, an attacker may induce the service to make unintended requests that exfiltrate information. MiddleBrick tests for SSRF by probing endpoints that accept URLs from user-controlled input, including values derived from token claims, and evaluates whether the service responds with sensitive data or internal network details.

Compliance mappings such as OWASP API Top 10 and GDPR highlight the severity of PII leakage. When tokens carry data that should be minimized and protected, the API increases its risk profile. MiddleBrick provides per-category breakdowns, showing how JWT-related findings contribute to the overall risk score and offering prioritized remediation steps aligned with recognized frameworks.

To mitigate PII leakage when using JWT tokens in Axum, limit the claims included in the token and avoid storing sensitive information. Use short-lived tokens and refresh mechanisms, and ensure all token handling occurs over TLS. The following examples demonstrate a secure implementation approach.

First, define a minimal claims structure that excludes PII:

use jsonwebtoken::{encode, decode, Header, Validation, Algorithm};
use serde::{Serialize, Deserialize};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String, // user identifier, non-PII
    exp: usize,  // expiration timestamp
    role: String, // non-sensitive role
}

Second, implement token creation with only necessary data:

fn create_token(user_id: &str, role: &str) -> String {
    let expiration = chrono::Utc::now()
        .checked_add_signed(chrono::Duration::hours(1))
        .expect("valid timestamp")
        .timestamp() as usize;

    let claims = Claims {
        sub: user_id.to_string(),
        exp: expiration,
        role: role.to_string(),
    };

    encode(
        &Header::default(),
        &claims,
        &EncodingKey::from_secret(&b"super-secret-key"[..]),
    ).expect("Failed to encode token")
}

Third, validate tokens without exposing claims in logs or responses:

fn validate_token(token: &str) -> Result<Claims, jsonwebtoken::errors::Error>
{
    decode::(
        token,
        &DecodingKey::from_secret(&b"super-secret-key"[..]),
        &Validation::new(Algorithm::HS256),
    ).map(|data| data.claims)
}

Finally, ensure middleware enforces token validation on all protected routes and that error messages do not reflect token contents. MiddleBrick’s CLI can be used to verify these patterns by scanning the endpoint and confirming that no PII appears in token payloads or error responses.