Path Traversal in Axum with Jwt Tokens

Path Traversal occurs when an API endpoint uses user-supplied input to construct file system paths without adequate validation or sanitization. In an Axum service that also handles JWT Tokens for authentication, a common pattern is to decode the token to extract a subject or claim (e.g., user ID) and use it to build paths such as ./uploads/{user_id}/file.txt. If the token or a downstream value is tampered with, an attacker can provide sequences like ../../../etc/passwd or use encoded Unicode to traverse directories and read or overwrite sensitive files. This becomes particularly risky when the JWT Token is parsed on the server but its claims are treated as trusted file-system identifiers without normalization or confinement.

For example, consider an Axum handler that decodes a JWT Token to obtain a user identifier and then appends it to a base directory to serve private documents. If the identifier is not confined to an allowed pattern, an attacker who obtains a valid token for one purpose might manipulate the token’s payload (if it’s not cryptographically verified per request) or supply a malicious path via query parameters to traverse outside the intended directory. Even when JWT Tokens are verified, a server-side request forgery or insecure direct object reference can compound path traversal if the token’s subject is used directly in file operations. The combination of Axum’s routing flexibility and JWT Token handling may inadvertently expose internal files if developers assume decoded claims are safe for path construction.

Real-world attack patterns mirror general path traversal techniques, such as using repeated sequences like ..%2F or double-encoded UTF-8 to bypass naive checks. In the context of JWT Tokens, an attacker might attempt to modify non-critical claims (e.g., sub or custom fields) before re-signing if key confusion or weak validation is present. While JWT Tokens themselves do not introduce path traversal, their usage in Axum can create a vector if the application uses token-derived values in file paths without strict allowlisting, normalization, or confinement. This is why runtime security checks that map OpenAPI/Swagger specs with execution findings are valuable for identifying mismatches between documented behavior and actual file system interactions.

To mitigate path traversal when working with JWT Tokens in Axum, ensure that any value derived from token claims is sanitized, confined, and never directly concatenated into file paths. Use allowlisted identifiers, normalize paths with a safe library, and enforce strict base directory confinement. Below are concrete code examples demonstrating secure handling.

First, validate and sanitize the user identifier from the JWT Token before using it in a path. Prefer a regex allowlist to ensure the identifier contains only expected characters (e.g., alphanumeric and underscores). Then, use Rust’s standard path facilities to prevent directory traversal components.

use axum::{routing::get, Router};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};
use std::path::{Path, PathBuf};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    // other claims omitted
}

async fn handle_file(user_id: String, filename: String) -> Result {
    // Validate user_id from JWT Token: allow only alphanumeric and underscore
    if !user_id.chars().all(|c| c.is_ascii_alphanumeric() || c == '_' || c == '-') {
        return Err("Invalid user identifier".into());
    }
    // Build a safe path using std::path::Path
    let base = Path::new("/safe/uploads");
    let user_dir = PathBuf::from(user_id);
    let requested_path = base.join(user_dir).join(filename);

    // Ensure the canonicalized path is still within the base directory
    let canonical_base = base.canonicalize().map_err(|e| e.to_string())?;
    let canonical_requested = requested_path.canonicalize().map_err(|e| e.to_string())?;
    if !canonical_requested.starts_with(&canonical_base) {
        return Err("Path traversal attempt detected".into());
    }

    // Proceed with safe file operations
    Ok(format!("Serving: {}", canonical_requested.display()))
}

// JWT verification example
async fn verify_and_extract_token(auth_header: &str) -> Result {
    let token = auth_header.trim_start_matches("Bearer ");
    let decoding_key = DecodingKey::from_secret("secret".as_ref());
    let validation = Validation::new(Algorithm::HS256);
    let token_data = decode::(token, &decoding_key, &validation)
        .map_err(|e| format!("Invalid token: {}", e))?;
    Ok(token_data.claims.sub)
}
"

Second, when serving files, avoid using raw user input for directory names. Instead, map the JWT Token subject to a constrained directory structure. For example, use a hash of the subject to derive a folder name, or use a database mapping to ensure only pre-approved paths are accessible.
use axum::extract::State;
use std::sync::Arc;

struct AppState {
    base_dir: String,
}

async fn serve_document(
    State(state): State>,
    // Assume user_id has been verified and extracted from JWT Token
    user_id: String,
    filename: String,
) -> Result {
    // Use a safe mapping: e.g., first two chars as subdirectory to avoid deep nesting
    let safe_subdir = if user_id.len() >= 2 {
        &user_id[..2]
    } else {
        &user_id
    };
    let path = format!("{}/{}/{}", state.base_dir, safe_subdir, filename);
    // Further validation as shown earlier
    Ok(path)
}
"

Finally, integrate middleBrick’s scans to detect path traversal and related issues in your Axum endpoints, especially when JWT Tokens are involved. Use the CLI to scan from the terminal: middlebrick scan <url>, or add the GitHub Action to your CI/CD pipeline to fail builds if risk scores drop below your threshold. For continuous monitoring, the Pro plan provides scheduled scans and alerts, while the MCP Server lets you scan APIs directly from your AI coding assistant within the IDE.