Token Leakage in Actix with Firestore

Token leakage in an Actix web service that uses Google Cloud Firestore occurs when authentication tokens or service account credentials are inadvertently exposed through API responses, logs, or error messages. Firestore typically requires a service account key or workload identity to authorize requests. If an Actix handler or middleware passes these credentials into a response body, a header, or a debug log, the token becomes accessible to unauthorized parties.

Actix is a Rust framework where handlers are asynchronous functions. If a handler builds a Firestore client per request and attaches it to the request extensions, developers might accidentally serialize the client or its inner auth data. For example, returning a Firestore client or its configuration struct as JSON (even via debug formatting) can expose encoded credentials or tokens. Because Firestore tokens are often short-lived OAuth2 access tokens, leaking one can allow an attacker to reuse it until expiry, depending on the token scope and replay protections of the identity provider.

Another common pattern is using Firestore security rules that reference request tokens or caller identity. If the Actix service forwards raw headers or cookies to Firestore without sanitization, a token included in an upstream header can be reflected in Firestore responses that the Actix app returns to the client. This reflection turns the Actix endpoint into a leakage channel. Additionally, if the application logs request context including authorization headers before interacting with Firestore, those logs can retain tokens and become a persistent exposure vector.

Consider an endpoint that accepts an authentication token, uses it to authorize Firestore reads, and then echoes user metadata back to the caller. A programming mistake might cause the handler to include the token in the JSON response, either directly or through an error path. In a microservice architecture where many endpoints share Firestore client instances, failing to isolate authentication state per handler can propagate tokens across responses. The risk is compounded when combined with insecure deserialization or improper content-type handling, which may cause clients to interpret token data as application payload.

middleBrick detects this class of issue under the Authentication and Data Exposure checks, alongside specific LLM/AI Security probes that look for token patterns in outputs. By correlating runtime responses with spec definitions, the scanner can highlight endpoints where tokens appear in headers or body, providing prioritized findings with severity and remediation guidance.

To prevent token leakage, design Actix handlers to keep Firestore credentials strictly server-side and avoid returning any authentication material to the client. Use Firestore’s server-side SDK with service account credentials stored securely in the environment, and ensure tokens are never serialized or logged.

Below is a safe Actix handler that creates a Firestore client once at startup, stores it in application state, and performs read operations without exposing tokens.

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use google_cloud_firestore::client::{Client, ClientConfig};
use std::sync::Arc;

async fn get_user_info(
    path: web::Path,
    data: web::Data>,
) -> impl Responder {
    let user_id = path.into_inner();
    // Read document using the shared client; no token is returned to the caller.
    match data.get_document(&format!("users/{}", user_id)).await {
        Ok(doc) => {
            // Extract only safe fields to return.
            let name: String = doc.get_field("name").unwrap_or_default();
            let email: String = doc.get_field("email").unwrap_or_default();
            HttpResponse::Ok().json(serde_json::json!({ "name": name, "email": email }))
        }
        Err(e) => {
            // Log the error internally without including tokens.
            tracing::error!(error = %e, "Failed to fetch user");
            HttpResponse::InternalServerError().json(serde_json::json!({ "error": "internal error" }))
        }
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // Load service account key from a secure path or environment variable.
    let config = ClientConfig::default().with_auth().await.expect("auth");
    let client = Arc::new(Client::new(config));

    HttpServer::new(move || {
        App::new()
            .app_data(web::Data::new(Arc::clone(&client)))
            .route("/users/{user_id}", web::get().to(get_user_info))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

Key practices to avoid token leakage in Actix with Firestore:

• Store service account keys outside the application binary, using environment variables or secret managers, and load them at startup.
• Never return Firestore client instances, configuration structs, or raw authentication headers from handlers.
• Sanitize any data forwarded to Firestore by removing or redacting authorization headers before the request is issued.
• Use structured logging that excludes sensitive headers and ensure logs are rotated and retained securely.
• Apply principle of least privilege to Firestore service accounts so that leaked tokens have minimal scope.

middleBrick’s scans can validate these mitigations by checking that authentication-related findings are absent from public endpoints and that no credentials appear in application outputs.