Cors Wildcard in Actix with Api Keys

A CORS wildcard (Access-Control-Allow-Origin: *) combined with API key authentication in Actix can unintentionally expose protected endpoints to any origin. In Actix-web, if the CORS middleware is configured with a wildcard while API key validation is applied as a guard or extractor, the presence of the key does not restrict which origins can use it. The browser enforces the CORS policy before the request reaches application logic, so a wildcard allows any web page to make authenticated requests on behalf of a user who possesses a valid key. This becomes critical when API keys are embedded in client-side code or leaked via referrer headers, as any site can trigger cross-origin calls that appear authorized.

In a black-box scan, middleBrick tests this combination by sending a preflight request with an origin and an API key header, checking whether the response includes a wildcard origin alongside a 200 status. If the endpoint returns Access-Control-Allow-Origin: * and does not reflect the requesting origin, the scan flags a CORS Wildcard finding even though API key authentication is present. This finding aligns with the Authentication and BOLA/IDOR checks, highlighting that authorization via API key is bypassed at the protocol level. Attack patterns such as CSRF-like cross-origin abuse become feasible when a key is valid and the origin is unrestricted, potentially leading to unauthorized operations captured in the Inventory Management and Unsafe Consumption checks.

For example, a route that reads /admin/reset with an API key header could be invoked from a malicious site if the CORS policy is a wildcard. The API key might be static or shared, and because the browser sends cookies and headers cross-origin per CORS rules, the request succeeds. middleBrick’s OpenAPI/Swagger analysis cross-references the spec’s securitySchemes with runtime CORS responses, detecting mismatches where a security scheme lists an API key but the server configuration permits any origin. This mismatch is surfaced in the report with remediation guidance, emphasizing the need to align CORS origins with trusted sources and avoid broad combinations with bearer-like credentials such as API keys.

To remediate CORS wildcard issues with API keys in Actix, explicitly set allowed origins to trusted domains and ensure the CORS middleware is applied after route definitions so that credentials and headers are validated before CORS checks. Use actix-cors to configure permissive methods while restricting origins, and avoid using a wildcard when API keys are exposed to client-side contexts. The following example demonstrates a secure Actix configuration where CORS allows only specific origins and API key validation is enforced via a guard.

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

async fn admin_reset(api_key: web::Header<String>) -> impl Responder {
    if api_key.into_inner() == "super-secret-key" {
        HttpResponse::Ok().body("Reset executed")
    } else {
        HttpResponse::Unauthorized().body("Invalid key")
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let cors = Cors::permissive()
        .allowed_origin("https://trusted.example.com")
        .allowed_method("GET")
        .allowed_header(actix_web::http::header::AUTHORIZATION)
        .allowed_header(actix_web::http::header::CONTENT_TYPE);

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

In this example, Cors::permissive() is limited with allowed_origin set to a specific trusted domain, preventing wildcard exposure. The API key is validated inside the handler, but the CORS policy ensures only pages from https://trusted.example.com can initiate requests. For broader origin lists, chain .allowed_origin(...) calls rather than using a wildcard. middleBrick’s Web Dashboard can track changes to this configuration over time, and the CLI tool (middlebrick scan <url>) can be integrated into testing to verify that the updated CORS policy no longer triggers a wildcard finding.

Additionally, consider moving API keys to server-side contexts where origins are not a factor, or use short-lived tokens if client-side usage is necessary. The GitHub Action can enforce a threshold so that any build introducing a wildcard with API keys fails, while the MCP Server allows you to scan APIs directly from your IDE during development. These integrations support the Pro plan’s continuous monitoring and CI/CD pipeline gates, helping maintain alignment with frameworks such as OWASP API Top 10 and PCI-DSS.