Cors Wildcard in Axum with Firestore

A CORS wildcard in an Axum service that exposes Firestore-backed endpoints broadens the attack surface by allowing origins that should not be trusted. In Axum, a permissive cors layer can be configured with AllowOrigins::all(), which responds to preflight requests with Access-Control-Allow-Origin: *. When this is combined with Firestore using service account credentials exposed via backend routes, the frontend can invoke privileged operations that were intended only for authenticated server-side code.

Consider a route that reads documents from Firestore using the Firestore Admin SDK. If Axum allows any origin, a malicious site can embed a script that calls this route, leveraging browser-based credentials (cookies or tokens) if the user is authenticated to your application. Even when Axum does not expose the service account key, overly broad CORS can allow unauthorized origins to inspect responses that contain Firestore document contents, potentially leaking sensitive data. This situation maps to OWASP API Top 10 A01:2023 broken object level authorization when combined with BOLA/IDOR-prone document references, and can be flagged by middleBrick as a high-severity finding in the BFLA/Privilege Escalation and Data Exposure checks.

In practice, an Axum app using the Firestore Rust SDK may look permissive by default if the developer does not explicitly constrain origins. The CORS middleware might return wildcard headers while the Firestore client is initialized with project-level credentials. middleBrick’s scan would detect the wildcard in Access-Control-Allow-Origin and flag it alongside unauthenticated or weakly constrained endpoints, noting risks such as unauthorized data retrieval or SSRF-like browser-driven access to Firestore through compromised frontends.

Real-world patterns from OWASP API Top 10 and CWE-942 underscore the need to replace the wildcard with a strict allowlist. Axum’s CORS configuration should enumerate trusted origins and avoid forwarding credentials to untrusted domains. When Firestore endpoints are involved, you should also ensure that tokens or session cookies are not sent cross-origin unless the origin is explicitly trusted, reducing the chance of illicit data exfiltration.

To remediate CORS wildcard issues in Axum when serving Firestore-backed APIs, explicitly configure allowed origins and tightly control which routes accept cross-origin requests. Below is a concrete Axum example with Firestore initialization and CORS settings that avoid wildcard usage.

use axum::Router;
use axum::routing::get;
use firestore::FirestoreDb;
use google_cloud_auth::credentials::CredentialsFile;
use std::net::SocketAddr;
use tower_http::cors::{CorsLayer, Any, Origin, HeaderValue};

#[tokio::main]
async fn main() {
    // Initialize Firestore client with a restricted service account
    let creds = CredentialsFile::new("path/to/service-account.json").unwrap();
    let db = FirestoreDb::new(&creds, "my-project-id").unwrap();

    // Define strict CORS policy: only your frontend origins
    let cors = CorsLayer::new()
        .allow_origin(Origin::exact("https://app.example.com".parse().unwrap()))
        .allow_origin(Origin::exact("https://staging.example.com".parse().unwrap()))
        .allow_methods(Any::some(&[axum::http::Method::GET, axum::http::Method::POST]))
        .allow_headers(Any::some(&[axum::http::header::CONTENT_TYPE, axum::http::header::AUTHORIZATION]))
        .expose_headers(HeaderValue::from_static("x-request-id"))
        .max_age(tower_http::cors::time::Duration::from_secs(3600));

    // Build routes with Firestore access, applying CORS only where needed
    let app = Router::new()
        .route("/api/docs/:doc_id", get(move |path: axum::extract::Path| async move {
            let doc_id = path.0;
            // Fetch a document from Firestore
            let doc: Option = db.get(&doc_id).await.ok().flatten();
            match doc {
                Some(data) => axum::response::Json(data),
                None => axum::response::Response::builder()
                    .status(404)
                    .body(axum::body::boxed(axum::body::boxed("Not found")))
                    .unwrap(),
            }
        }))
        .layer(cors); // CORS applied selectively

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

Key points in this configuration:

• Origins are enumerated explicitly rather than using a wildcard, preventing arbitrary sites from invoking Firestore routes.
• Credentials are not forwarded to untrusted origins because allow_credentials is not set globally; only specific origins can send cookies or authorization headers if you additionally configure .allow_credentials(true) on selected origins.
• The Firestore client is initialized with a service account key, but the backend routes are not exposed to the browser unless CORS permits them, reducing the risk of browser-based abuse.

If you use the middleBrick CLI (middlebrick scan <url>) or GitHub Action, this setup will lower your risk score in the CORS and Data Exposure checks. The Pro plan’s continuous monitoring can alert you if a wildcard reappears after changes, and the MCP Server can surface these issues directly in your IDE while you develop.