Zip Slip in Actix with Jwt Tokens

Zip Slip is a path traversal vulnerability that occurs when an API constructs file system paths using user-supplied input without proper validation. In an Actix-web service that also uses JWT tokens for authentication, the combination can expose authorization bypass and arbitrary file read risks. Consider an endpoint that extracts a filename from a JWT claim (for example, a "document_id" claim) and uses it to build a local path without canonicalization or strict allowlisting. If the JWT payload is trusted implicitly, an attacker who can influence the token (via a weak signing key, token leakage, or a compromised client) can supply crafted input such as ../../../etc/passwd. Because Actix handlers often resolve paths relative to a configured base directory, the traversal sequences can resolve outside that directory, leading to unauthorized file access. This becomes particularly dangerous when the JWT also carries role or scope claims that the server uses to gate behavior, since path traversal can expose configuration files or logs that further weaken authentication or reveal signing secrets. In black-box scanning, middleBrick tests such scenarios by submitting unauthenticated probes where JWT-like inputs are treated as potentially manipulated, checking whether path traversal or information disclosure is detectable without relying on authenticated sessions.

Remediation focuses on strict input validation, canonical path resolution, and avoiding trust in JWT claims for filesystem decisions. Below are concrete Actix-web patterns to mitigate Zip Slip when JWT tokens are involved.

1. Validate and sanitize filename inputs

Never directly use a value from a JWT claim in a filesystem path. Normalize and validate the filename against an allowlist or a strict pattern. Use the sanitize-filename crate or equivalent to remove or replace dangerous characters.

use sanitize_filename::sanitize;

fn safe_filename(input: &str) -> String {
    sanitize(input)
        .chars()
        .take(255)
        .collect()
}

2. Use canonical paths and a configured base directory

Resolve paths with std::fs::canonicalize and ensure the resulting path starts with the intended base directory. This prevents traversal sequences from escaping the intended directory even if the input is manipulated via a JWT claim.

use std::path::{Path, PathBuf};

fn resolve_base_path(base: &Path, user_segment: &str) -> std::io::Result<PathBuf> {
    let safe_name = safe_filename(user_segment);
    let candidate = base.join(safe_name);
    let canonical = candidate.canonicalize()?;
    if canonical.starts_with(base) {
        Ok(canonical)
    } else {
        Err(std::io::Error::new(
            std::io::ErrorKind::PermissionDenied,
            "path escape detected",
        ))
    }
}

// Usage in an Actix handler:
// let path = resolve_base_path(Path::new("/var/data"), &filename).await?;

3. Avoid JWT claims for filesystem paths

Treat JWTs as authentication assertions, not as sources of filesystem metadata. If you must reference resources, map JWT subject or custom claims to internal IDs that your server resolves through a controlled database or index, rather than building paths directly from claim values.

// Example mapping in Actix:
// let claims: MyClaims = validate_token(&auth_header)?;
// let file_id: Uuid = claims.file_id;
// let file_record = db.get_file_record(file_id).await?;
// let storage_path = Path::new("/secure_storage").join(file_record.safe_path);

4. Enforce least privilege and logging

Run the Actix service with a dedicated OS user and minimal filesystem permissions. Log path resolution attempts, especially when a path is rejected due to traversal patterns, to support incident investigation. Combine these practices with regular dependency updates to mitigate related supply-chain risks.

Using middleBrick, you can verify that such remediations reduce the detectable attack surface by scanning unauthenticated endpoints and observing whether traversal indicators and JWT-related exposures are still reported.