Api Key Exposure in Actix with Firestore

When an Actix web service is configured to interact with Google Cloud Firestore, Api Key Exposure typically arises from how API keys are stored, passed, and logged in the application. In this combination, the risk occurs when an API key intended for Firestore access is embedded into Actix route handlers, middleware, or configuration that is reachable through unauthenticated or improperly constrained endpoints.

Firestore requires an API key or service account credentials for outbound requests. If an Actix application bundles the key into query parameters, request bodies, or HTTP headers that are reflected in responses or logs, the key can be exfiltrated by an attacker who triggers those endpoints. Because middleBrick scans the unauthenticated attack surface, it can detect exposed keys in responses, overly permissive CORS settings, or debug endpoints that echo configuration details.

Another exposure path is through source code or build artifacts that are inadvertently served by Actix static file handling. If a configuration file containing the Firestore API key is placed within the web-accessible directory, the file can be downloaded directly. middleBrick’s Data Exposure checks specifically look for sensitive strings such as API keys in responses and can surface these findings with severity and remediation guidance.

SSRF interactions compound the issue: an Actix endpoint that accepts a user-supplied URL and forwards it to Firestore REST endpoints may allow an attacker to force the server to leak its configured key through error messages or metadata endpoints. The scanner tests SSRF patterns and can identify whether Firestore hostnames appear in reflected content, indicating a potential path for key exposure.

Additionally, logging practices in Actix applications can inadvertently record API keys if request data containing the key is written to logs without sanitization. middleByte’s checks include output scanning for API keys and PII, which helps identify whether runtime responses or error payloads disclose sensitive material.

Remediation centers on keeping Firestore credentials out of request/response flows and enforcing strict access controls. Do not embed API keys in routes or query parameters. Instead, use environment variables or a secure secrets manager, and ensure keys are loaded only at startup by server-side code that is not reachable via HTTP.

Use the official Firestore client libraries with service account credentials scoped to least privilege, rather than public API keys, for server-to-server operations. Configure the Actix application to initialize the Firestore client once during application startup and reuse it across requests. This avoids embedding keys in per-request logic and reduces exposure surfaces.

Enforce strict CORS policies so that browser-based clients cannot inadvertently trigger authenticated requests that might leak keys. Validate and sanitize all inputs before constructing Firestore queries to avoid injection or SSRF-based key leakage. Disable directory listing and ensure static assets do not include configuration files.

Below are concrete, secure examples for an Actix service that interacts with Firestore using a server-side client initialized from environment variables, avoiding exposure in HTTP flows.

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use google_cloud_rust::firestore::client::{FirestoreClient, FirestoreClientConfig};
use std::env;

// Initialize Firestore client once at startup using a service account key file path
// stored securely as an environment variable, not exposed via HTTP endpoints.
async fn init_firestore() -> Result> {
    let project_id = env::var("GCP_PROJECT_ID").expect("GCP_PROJECT_ID must be set");
    let key_path = env::var("FIRESTORE_KEY_PATH").expect("FIRESTORE_KEY_PATH must be set");
    let config = FirestoreClientConfig::new(project_id, Some(key_path));
    FirestoreClient::new(config).await.map_err(Into::into)
}

// Example handler that uses the pre-initialized client to read a document.
// No API key is present in the request or response.
async fn get_user(
    client: web::Data<FirestoreClient>,
    path: web::Path<String>
) -> impl Responder {
    let user_id = path.into_inner();
    // Read from Firestore using server-authenticated client; key is not exposed.
    match client.get_document(&format!("users/{}", user_id)).await {
        Ok(doc) => HttpResponse::Ok().json(doc),
        Err(err) => HttpResponse::InternalServerError().body(err.to_string()),
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // Initialization fails early if credentials are missing or invalid.
    let client = web::Data::new(init_firestore().await.expect("Firestore client init failed"));
    HttpServer::new(move || {
        App::new()
            .app_data(client.clone())
            .route("/users/{id}", web::get().to(get_user))
            // Enforce strict CORS to prevent unauthorized origins.
            .wrap(
                actix_cors::Cors::permissive() // In production, replace with strict allow list.
            )
    })
    .bind("0.0.0.0:8080")?
    .run()
    .await
}

For applications that must use API keys (for example, to call Firestore REST endpoints directly), ensure keys are passed only from server-side code and never reach the client. Configure Actix to strip or redact sensitive headers from logs and responses, and use middleware that rejects requests containing key-like values in headers or bodies to prevent accidental echo.

middleBrick can validate these protections by scanning the exposed endpoints and confirming that no API keys appear in responses, that CORS is restrictive, and that error messages do not disclose configuration details. Its findings include severity ratings and remediation steps mapped to frameworks such as OWASP API Top 10 and SOC2.