Cors Wildcard in Actix (Rust)

Cross-Origin Resource Sharing (CORS) misconfigurations are a common web vulnerability. In Actix web applications written in Rust, using a wildcard origin (*) while also allowing credentials or sensitive headers can expose sensitive data and enable unauthorized cross-site requests. When an Actix service uses .wrap(Cors::default().allow_any_origin()), the server explicitly permits any origin to make requests and potentially read responses if credentials or headers are also permissive. This pattern is problematic because browsers will include cookies or authorization headers when the frontend origin is controlled by an attacker, leading to data exposure or Cross-Site Request Forgery (CSRF)-like scenarios in cross-origin contexts.

Additionally, combining wildcard origins with methods like .allow_any_origin().allow_credentials(true) is invalid in many CORS implementations and can result in unsafe runtime behavior or inconsistent enforcement. Actix-CORS will often reject such combinations at runtime, but developers may not notice misconfiguration if responses appear to work during development. Attackers can probe these endpoints using simple JavaScript fetch requests from malicious origins to observe whether CORS headers are improperly permissive, which could facilitate unauthorized access to user-specific endpoints that rely on session cookies.

In the context of API security scanning, middleBrick checks for CORS misconfigurations by inspecting response headers and validating that origins, methods, and headers follow least-privilege principles. It flags wildcard origins in combination with exposed sensitive headers or credentials as a high-severity finding. This is especially relevant for Rust-based Actix services that serve both API and web frontend traffic, where developers might unintentionally expose user data via overly permissive CORS rules.

To secure an Actix web application in Rust, configure CORS with explicit origins and restrict methods and headers instead of relying on wildcards. Below are two concrete, syntactically correct examples demonstrating insecure and secure configurations.

Insecure example — wildcard origin with credentials (vulnerable):

use actix_cors::Cors;
use actix_web::{web, App, HttpServer};

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .wrap(Cors::default().allow_any_origin().allow_credentials(true))
            .route("/api/user", web::get().to(user_handler))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

This configuration is unsafe because it allows any origin to access authenticated responses, exposing user sessions if a malicious site triggers requests from a user’s browser.

Secure example — restricted origins and headers (recommended):

use actix_cors::Cors;
use actix_web::{web, App, HttpServer};

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let cors = Cors::default()
        .allowed_origin("https://trusted.example.com")
        .allowed_methods(vec!["GET", "POST"])
        .allowed_header(actix_web::http::header::AUTHORIZATION)
        .allowed_header(actix_web::http::header::CONTENT_TYPE)
        .max_age(3600);

    HttpServer::new(move || {
        App::new()
            .wrap(cors.clone())
            .route("/api/user", web::get().to(user_handler))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

In this secure configuration, only requests from https://trusted.example.com are permitted, and only for specified HTTP methods and headers. This reduces the attack surface and ensures that credentials or sensitive headers are not exposed cross-origin. For development convenience, you can allow localhost explicitly without using a wildcard:

.allowed_origin("http://localhost:3000")

middleBrick can validate these settings by scanning your Actix service and reporting whether response headers include Access-Control-Allow-Origin: * alongside credentials, which would trigger a high-severity finding. The scanner also checks whether exposed headers inadvertently leak sensitive data, helping teams enforce least-privilege CORS policies in Rust-based APIs.