Fix Improper Assets Management in Actix Web

Improper Asset Management in Actix Web typically stems from over-privileged file handlers and 'shadow' endpoints that expose internal configuration or source code. In Rust, utilizing actix-files without strict directory scoping or enabling directory listings allows attackers to map your application structure and extract sensitive files like .env, Cargo.toml, or private SSH keys.

The Vulnerable Pattern

use actix_files::Files;
use actix_web::{App, HttpServer};
#[actix_web::main]
async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
// VULNERABILITY: Serving the project root (’.’) and enabling directory listing
// This exposes source code, secrets, and internal build artifacts.
.service(Files::new(“/static”, ”.“).show_files_listing())
})
.bind(“127.0.0.1:8080”)?
.run()
.await
}

The Secure Implementation

To mitigate improper asset management, follow the principle of isolation. First, move all public-facing assets into a dedicated subdirectory (e.g., /public/static) that contains no sensitive logic or configuration. Second, remove the '.show_files_listing()' call; listing files provides a roadmap for automated scrapers and attackers. Third, never mount the application root ('.') or the target directory as the source for actix_files. Finally, ensure your CI/CD pipeline strips unnecessary files from the production environment to prevent 'forgotten' assets from being served.

use actix_files::Files;
use actix_web::{App, HttpServer};
#[actix_web::main]
async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
// SECURE: Scope files to a specific, isolated subdirectory.
// show_files_listing is disabled by default.
.service(
Files::new(“/assets”, ”./public/static”)
.use_last_modified(true)
.prefer_utf8(true)
)
})
.bind(“127.0.0.1:8080”)?
.run()
.await
}