Api Key Exposure in Axum with Firestore

When an Axum service is configured to authorize requests using static API keys and those keys are stored or referenced in a Firestore-backed configuration store, the risk of Api Key Exposure increases due to the convergence of application-level routing and external data access. Axum, a Rust web framework, typically loads configuration at startup, which may include API keys used to authorize outbound calls to third-party services. If these keys are retrieved from a Firestore collection at runtime or during initialization without strict access controls, the keys may be exposed in logs, error messages, or through insecure service account permissions.

Firestore rules that are misconfigured for public read access can inadvertently expose sensitive configuration data. For example, a Firestore document containing a key named EXTERNAL_SERVICE_TOKEN may be readable by unauthenticated users if the security rules lack explicit allow conditions. In an Axum application that fetches this document on each request or caches it in memory, the key can propagate into server logs when the application prints debug information or when middleware captures request metadata. This creates a chain of exposure: Firestore misconfiguration leads to key leakage, and Axum’s runtime behavior amplifies the risk through logging and error handling.

Another vector involves service-to-service communication where Axum endpoints act as proxies. If an Axum route accepts an API key from a client and forwards it to Firestore operations without validation, an attacker may intercept or manipulate the key through injection or man-in-the-middle techniques within the application layer. The key may also appear in serialized responses or error traces when Firestore returns permission-denied messages that include document paths or metadata. Because Axum does not inherently sanitize outbound data structures, developers must explicitly filter sensitive values before logging or transmitting them.

The combination of Axum’s flexible routing and Firestore’s document-based storage means that any weak rule or improper secret management pattern can lead to Api Key Exposure. Common triggers include using default Firestore emulator keys in production, storing keys in documents without encryption at rest, or failing to rotate keys after team member offboarding. middleBrick scans such configurations during unauthenticated black-box testing and flags exposed or overly permissive Firestore rules alongside risky Axum endpoint behaviors, highlighting findings tied to the Authentication and Data Exposure checks.

Real-world attack patterns mirror these risks, such as an unauthenticated attacker querying a public Firestore endpoint to extract API keys used by Axum services, then reusing those keys to impersonate backend systems. This aligns with the OWASP API Top 10 category of Broken Object Level Authorization when Firestore documents act as indirect authorization stores. By correlating runtime behavior with configuration exposure, middleBrick provides findings that map to compliance frameworks and deliver prioritized remediation guidance specific to this stack.

To mitigate Api Key Exposure in Axum when using Firestore, implement strict access controls, avoid runtime key exposure, and structure application logic to minimize the risk of accidental leakage. The following code examples demonstrate secure patterns for integrating Firestore with Axum, focusing on configuration loading, request handling, and error management.

First, load API keys from Firestore at startup using a service account with least-privilege permissions, and store them in Axum’s runtime state instead of fetching them per request. Use environment variables or secure vaults for initial credentials, and ensure Firestore security rules deny public access.

use axum::{routing::get, Router};
use firestore::FirestoreDb;
use serde::Deserialize;
use std::sync::Arc;

#[derive(Deserialize, Clone)]
struct AppConfig {
    external_api_key: String,
}

async fn load_config() -> Result> {
    // Initialize Firestore client with a restricted service account
    let db = FirestoreDb::new("my-project-id").await?;
    let doc: AppConfig = db.get_doc("config", "api_keys").await?;
    Ok(doc)
}

#[tokio::main]
async fn main() {
    let config = load_config().expect("Failed to load config");
    let app = Router::new()
        .route("/health", get(|| async { "ok" }))
        .with_state(Arc::new(config));

    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())
        .serve(app.into_make_service())
        .await
        .unwrap();
}

Second, sanitize any data derived from Firestore before logging or sending it to downstream services. Never include raw API keys in structured logs or error responses. Instead, use opaque identifiers or hashes for debugging purposes.

use axum::{http::StatusCode, response::IntoResponse};

async fn handle_request(config: Arc<AppConfig>) -> Result {
    // Use the key internally without exposing it in logs
    let result = external_service_call(&config.external_api_key).await;
    match result {
        Ok(data) => Ok(data),
        Err(e) => {
            // Log only a sanitized message
            tracing::error!(error = %e, "external call failed");
            Err((StatusCode::INTERNAL_SERVER_ERROR, "request failed".into()))
        }
    }
}

Third, enforce strict Firestore security rules that limit read access to authenticated and authorized service accounts only. Avoid rules that allow read access based solely on request origin without verifying service identity.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /config/api_keys {
      allow read: if request.auth != null && request.auth.token.service_account == "[email protected]";
      allow write: if false;
    }
  }
}

Finally, rotate keys regularly and monitor access patterns. Use Firestore’s audit logs to detect unusual read activity on sensitive documents. In Axum, implement middleware that validates outbound requests and ensures keys are not inadvertently included in URLs or query parameters that could be captured in logs.