Cors Wildcard in Actix with Firestore

Using a CORS wildcard (*) in an Actix web service that exposes a Firestore-backed API can unintentionally grant broader access than intended. When the server sets Access-Control-Allow-Origin: * and also includes credentials—either via Access-Control-Allow-Credentials: true or because the browser sends cookies—a browser will block the frontend from reading the response, but the server’s permissive configuration may still allow any origin to invoke the endpoints. In a Firestore context, this often means any website can make authenticated calls to your backend routes that read or write Firestore documents.

Actix routes typically define CORS policies explicitly. If the policy is constructed with .allow_any_origin() alongside .supports_credentials(), the combination is invalid per the CORS specification and results in a non‑configurable allow‑origin header. An attacker can craft a page that loads your Firestore API via fetch or XMLHttpRequest, potentially leveraging stored authentication tokens in cookies or Authorization headers. Because Firestore security rules operate on the backend and do not restrict CORS, the vulnerability manifests as an overly permissive CORS policy that facilitates unauthorized cross-origin requests to Firestore endpoints.

For example, consider an Actix handler that queries a Firestore collection without validating the origin of the request. If CORS permits any origin, a malicious site can initiate requests that expose sensitive Firestore data or trigger write operations, depending on the authentication state of the user. Even though Firestore enforces its own security rules, the CORS misconfiguration removes a layer of enforcement by allowing browsers to interact with the API from unintended origins. This becomes especially critical if the Firestore rules rely on identifying the user via an ID token passed in an Authorization header, as any site can include that header when making cross-origin requests if the server permits credentials.

To identify this using middleBrick, you can run a scan against your Actix service endpoint. The tool performs unauthenticated checks across multiple categories, including CORS misconfiguration, and maps findings to frameworks such as OWASP API Top 10. If a wildcard origin with credentials is detected, middleBrick reports a finding with severity and remediation guidance, helping you tighten the CORS policy without disrupting legitimate clients.

Remediation centers on tightening the CORS configuration and ensuring Firestore security rules align with the intended access model. In Actix, replace .allow_any_origin() with specific origins and explicitly allow credentials only when necessary. Use .allowed_origin to list trusted front‑end domains and set .allow_credentials to true only for those origins.

Below are concrete Rust examples using the Actix CORS middleware and a Firestore read operation. The first snippet shows a secure CORS policy:

use actix_cors::Cors; Cors {
    Cors::default()
        .allowed_origin("https://app.yourdomain.com")
        .allowed_origin("https://staging.yourdomain.com")
        .allowed_methods(vec!["GET", "POST"])
        .allowed_headers(vec![actix_web::http::header::AUTHORIZATION, actix_web::http::header::ACCEPT])
        .allow_credentials()
        .max_age(3600)
}

Next, integrate this CORS configuration with your Firestore client. The following example demonstrates an Actix handler that retrieves a document from Firestore using the official Google Cloud Firestore client for Rust, assuming appropriate bindings or REST calls are wrapped accordingly. For illustration, we show the handler structure and how to pass the Firestore project ID and document path:

use actix_web::{get, web, HttpResponse};
use google_cloud_firestore::client::Client;
use google_cloud_firestore::document::Document;

#[get("/document/{collection}/{document_id}")]
async fn get_document(
    path: web::Path<(String, String)>,
    client: web::Data<Client>,
) -> HttpResponse {
    let (collection, document_id) = path.into_inner();
    let doc_ref = client.collection(&collection).doc(&document_id);
    match doc_ref.get().await {
        Ok(document) => HttpResponse::Ok().json(document),
        Err(e) => HttpResponse::InternalServerError().body(e.to_string()),
    }
}

Ensure that Firestore security rules enforce user-specific access. For example, if you use Firebase Authentication, rules can scope reads and writes to the authenticated user’s data:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Combine these measures: specific origins in Actix CORS, credential handling only for trusted domains, and Firestore rules that validate authentication and scope by user ID. This reduces the risk of cross-origin abuse while preserving functionality for your registered front‑ends.

middleBrick’s dashboard can track your API’s CORS-related findings over time, and the CLI can be integrated into CI/CD to fail builds if risky configurations are detected. The MCP server allows you to run scans directly from AI coding assistants, helping you catch such issues earlier in development.