Path Traversal in Actix with Bearer Tokens

Path Traversal occurs when user-controlled input is used to construct file system paths without proper validation, allowing an attacker to access files outside the intended directory. In Actix web applications, this typically manifests through endpoints that accept file identifiers or paths as parameters and directly concatenate them with a base directory. When Bearer Tokens are involved, the risk pattern shifts: the token itself may be treated as user input, or the application may use the token to derive a file path, such as storing per-token resources or logs.

Consider an Actix handler that retrieves a user’s private document using an ID provided in the request. If the handler builds a filesystem path like format!("/data/{}/document.pdf", document_id) and document_id comes from an unvalidated query parameter or header, an attacker can supply ../../../etc/passwd to read arbitrary files. The presence of a Bearer Token in the Authorization header does not inherently protect against this; if the application uses the token to locate a user-specific folder (e.g., format!("/users/{}/files/{}", token, document_id)) and both values are unescaped, traversal becomes possible across user boundaries or into system directories.

In a black-box scan, middleBrick tests for Path Traversal by sending sequences like ..%2F, URL-encoded slashes, and null byte injections against endpoints that accept path-like inputs. When Bearer Tokens are present, the scanner includes valid and invalid tokens to verify whether authorization checks are bypassed and whether token-derived paths are sanitized. An insecure implementation might treat the token as a directory name without normalization, enabling an attacker who obtains or guesses a token to traverse out of that token’s intended scope. The scanner also checks whether the server returns different responses for unauthorized traversal attempts versus authorized ones, which can reveal inconsistent access control logic.

Real-world examples align with OWASP API Top 10 A01:2023 broken object level authorization and A05:2023 security misconfiguration. Instances where log or configuration files are exposed due to insufficient path validation are common in microservices that use file-based storage for artifacts tied to authentication contexts. middleBrick’s OpenAPI/Swagger analysis helps identify endpoints with path parameters and then correlates them with security findings to highlight where traversal risks intersect with token-based access schemes.

Because middleBrick scans the unauthenticated attack surface, it can detect endpoints that inadvertently expose path traversal regardless of whether a Bearer Token is supplied. If an endpoint requires a token but still reflects path traversal indicators in error messages or directory listings, the scanner flags these as high-severity findings. Developers should treat Bearer Tokens as opaque identifiers and never use them directly in filesystem operations without strict validation, normalization, and confinement to a designated base directory.

Remediation centers on strict input validation, path normalization, and avoiding direct concatenation of user or token values into filesystem paths. In Actix, you should treat Bearer Tokens as opaque strings and never derive filesystem paths from them. Instead, map tokens to internal user identifiers and confine all file operations to a dedicated, application-controlled base directory.

Use Rust’s standard library functions to sanitize paths. The std::path::Path API, combined with clean logic and explicit prefix checks, ensures that any attempted traversal remains within allowed boundaries. Below is an example of a secure Actix handler that accepts a document ID via a path parameter, validates it, and serves a file from a user-specific directory derived from an authenticated user ID (not the Bearer Token string itself).

use actix_web::{web, HttpResponse, Result};
use std::path::{Path, PathBuf};

// Assume user_id is resolved from session/JWT claims, not from the Bearer Token string
fn resolve_user_directory(user_id: &str) -> PathBuf {
    let base = Path::new("/safe/base/directory");
    base.join(user_id)
}

async fn get_document(
    user_id: String,
    document_id: web::Path,
) -> Result {
    // Validate document_id: allow only alphanumeric, underscores, hyphens
    if !document_id.chars().all(|c| c.is_alphanumeric() || c == '_' || c == '-') {
        return Ok(HttpResponse::BadRequest().body("Invalid document identifier"));
    }

    let user_dir = resolve_user_directory(&user_id);
    // Ensure user_dir is within the base directory
    let base_dir = Path::new("/safe/base/directory");
    if !user_dir.starts_with(base_dir) {
        return Ok(HttpResponse::Forbidden().body("Access denied"));
    }

    let file_path = user_dir.join(document_id).with_extension("pdf");
    if !file_path.exists() || !file_path.is_file() {
        return Ok(HttpResponse::NotFound().body("File not found"));
    }

    // Use actix_files::NamedFile or similar to safely serve the file
    actix_files::NamedFile::open(file_path)
        .map_err(|_| actix_web::error::ErrorNotFound("File not found"))
        .map(|file| file.into_response(&actix_web::dev::ServiceRequest::default()))
}

If your application must reference resources by an external identifier (such as a Bearer Token), map the token to a user record in a database and use the record’s stable ID for file operations. This prevents attackers from leveraging token formats or information leakage in token strings.

Additionally, configure middleware to strip or reject unexpected Authorization header formats that could be used to probe traversal behavior. Combine this with runtime security tooling flagged by middleBrick’s continuous monitoring (available in the Pro plan) to detect regressions. The GitHub Action can enforce a minimum security score before allowing merges, reducing the chance of deployment vulnerabilities.

For teams using the Web Dashboard, tracking scores over time helps ensure that fixes remain effective as endpoints evolve. The MCP Server integration allows you to scan APIs directly from your AI coding assistant, embedding security checks into development workflows without disrupting existing pipelines.