Symlink Attack in Actix with Bearer Tokens

A symlink attack in an Actix web service becomes high risk when endpoints protected by Bearer token authentication rely on file system operations to locate or serve token-related artifacts such as certificates, keys, or token metadata. If an API exposes a file path derived from user-supplied input—often an identifier or a filename—and does not resolve the path to its real location before acting on it, an attacker can replace the intended file with a symlink that points to a sensitive resource. Because the request carries a Bearer token, the server may treat the request as authorized and follow the symlink, inadvertently reading or overwriting files that should be inaccessible to the client.

Consider an Actix endpoint that retrieves a token revocation list from a file path constructed using a user-provided token identifier:

use actix_web::{web, App, HttpServer, Responder};
use std::fs;

async fn get_revocation_list(info: web::Path) -> impl Responder {
    let base = "/var/tokens/revoked/";
    let file_path = format!("{}{}", base, info);
    match fs::read_to_string(file_path) {
        Ok(content) => format!("Revocation List: {}", content),
        Err(_) => "Not found".into(),
    }
}

If the info segment is not canonicalized, an attacker can supply a value such as ../../../etc/passwd or a crafted relative path that traverses directories. When the application joins this input to the base directory, the resulting path can escape the intended directory. If a symlink exists from a benign file within the token directory to a sensitive system file, the server will follow the symlink and expose data it did not intend to expose. The presence of a Bearer token may also encourage developers to assume that filesystem access is already protected by authentication, leading to insufficient validation of file paths.

In a scenario where token metadata is stored on disk and exposed via an administrative endpoint, an attacker who can influence filename resolution can use directory traversal and symlink placement to read other users’ token information or configuration files. This becomes particularly dangerous when combined with insecure default configurations or shared hosting environments where symlink races are easier to exploit. The API may appear to enforce token-based access at the HTTP layer, while the underlying file access logic remains vulnerable to manipulation at the filesystem level.

To mitigate symlink risks while still using Bearer tokens in Actix, ensure that any file path construction is strictly controlled and that paths are resolved to their canonical, real locations before use. Do not concatenate user input directly into filesystem paths. Instead, validate and sanitize identifiers, and use an allowlist or mapping to relate tokens to safe filesystem locations.

The following example demonstrates a safer approach using path sanitization and canonical resolution within an Actix handler:

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

fn safe_path(user_input: &str, base: &Path) -> Option {
    // Allow only alphanumeric tokens, or use a mapping to safe filenames
    if !user_input.chars().all(|c| c.is_ascii_alphanumeric()) {
        return None;
    }
    let candidate = base.join(user_input);
    // Canonicalize to resolve symlinks and normalize the path
    match candidate.canonicalize() {
        Ok(real) => {
            // Ensure the resolved path is still within the intended base directory
            if real.starts_with(base) {
                Some(real)
            } else {
                None
            }
        }
        _ => None,
    }
}

async fn get_revocation_list_safe(path: web::Path) -> HttpResponse {
    let base = Path::new("/var/tokens/revoked/");
    match safe_path(&path, base) {
        Some(file_path) => {
            match fs::read_to_string(file_path) {
                Ok(content) => HttpResponse::Ok().body(format!("Revocation List: {}", content)),
                Err(_) => HttpResponse::NotFound().body("Not found"),
            }
        }
        None => HttpResponse::BadRequest().body("Invalid path"),
    }
}

In this pattern, the handler first validates the input to prevent traversal characters, then uses Path::canonicalize to resolve any symlinks and confirm that the final path remains inside the authorized directory. This ensures that even if a symlink exists in the token storage area pointing elsewhere, the server will not follow it outside the intended scope. The same principles apply when serving certificates or keys associated with Bearer token verification, where file paths should be derived from a controlled mapping rather than direct user input.

For production deployments, pair these filesystem safeguards with secure handling of Bearer tokens at the HTTP layer, including strict scope validation and short lifetimes. Combine runtime scanning with continuous monitoring to detect unexpected file access patterns. Tools such as the middleBrick CLI can be integrated into development workflows using middlebrick scan <url> to identify path traversal and symlink-related findings, while the GitHub Action can enforce security gates in CI/CD pipelines. The MCP Server enables these checks directly from IDEs, helping developers catch risky path handling early.