Path Traversal in Axum with Basic Auth

Path Traversal occurs when user-controlled input used to resolve file paths allows directory traversal sequences (e.g., ../) to escape a intended directory. In Axum, this commonly arises when route parameters or query values are directly passed to filesystem operations such as tokio::fs::read or when building file paths for static assets. Combining this with Basic Auth can expose subtle risks: the authentication layer may log or reflect credentials in a way that aids an attacker while the application itself serves files based on manipulated paths.

For example, an endpoint like /files/{filename} that resolves paths relative to a base directory can be abused if the filename parameter includes sequences like ../../etc/passwd. Even when Basic Auth is enforced via middleware, a misconfigured route or permissive CORS/preflight behavior can allow unauthenticated or partially authenticated traversal attempts to reach filesystem logic. Moreover, if error messages from Axum handlers leak absolute paths or directory structures, they can guide an attacker to refine traversal patterns. Because middleBrick tests unauthenticated attack surfaces, it can detect endpoints where traversal is possible despite Basic Auth being present, highlighting mismatches between authentication enforcement and input validation.

During a scan, middleBrick evaluates whether path parameters are properly sanitized and whether framework-level guards prevent directory escapes. Findings may include missing validation, overly permissive route patterns, or unsafe use of libraries like tokio::fs that do not canonicalize paths. The LLM/AI Security checks additionally probe whether authentication prompts or error responses can be abused to reveal hints useful for traversal attacks, ensuring coverage beyond conventional checks.

Secure handling in Axum requires strict input validation, path canonicalization, and careful use of authentication middleware. Avoid concatenating user input directly into filesystem paths. Instead, resolve paths against a strict base directory and ensure the resolved path remains within that directory. Use middleware to enforce Basic Auth and validate credentials before allowing access to file-serving routes.

Secure Basic Auth middleware in Axum

Implement a middleware layer that validates Basic Auth credentials and attaches identity information to requests. The following example shows a minimal, production-grade approach using tower::Service and axum::extract::Request:

use axum::{http::Request, async_trait, extract::FromRequestParts};
use axum::extract::request::Parts;
use std::convert::Infallible;
use headers::authorization::Authorization;
use headers::Authorization as AuthHeader;
use std::net::SocketAddr;
use tower_http::auth::Authorization as TowerAuth;

struct Authenticated;

#[async_trait]
impl FromRequestParts for Authenticated
where
    S: Send + Sync,
{
    type Rejection = (http::StatusCode, &'static str);

    async fn from_request_parts(parts: &mut Parts, _state: &S) -> Result {
        let auth_header = parts.headers.get("authorization")
            .and_then(|h| h.to_str().ok())
            .and_then(|s| s.strip_prefix("Basic "))
            .ok_or((http::StatusCode::UNAUTHORIZED, "missing or invalid auth"))?;

        // In real code, decode and validate credentials securely
        let decoded = base64::decode(auth_header).map_err(|_| (http::StatusCode::UNAUTHORIZED, "invalid encoding"))?;
        let creds = String::from_utf8(decoded).map_err(|_| (http::StatusCode::UNAUTHORIZED, "invalid credentials"))?;
        let parts: Vec<&str> = creds.splitn(2, ':').collect();
        if parts.len() != 2 || parts[0] != "admin" || parts[1] != "secret" {
            return Err((http::StatusCode::UNAUTHORIZED, "bad credentials"));
        }
        Ok(Authenticated)
    }
}

async fn file_handler(
    Authenticated(_auth): Authenticated,
    axum::extract::Path(filename): axum::extract::Path,
) -> Result {
    // Safe path resolution follows
}