Stack Overflow in Actix with Firestore

A stack overflow in an Actix web service that uses Firestore as a backend can occur when recursive data structures or unbounded recursion are introduced between the HTTP request handling layer and the Firestore document traversal logic. For example, if an Actix handler recursively follows document references in Firestore without a depth limit, each request can create nested Firestore read calls that consume stack frames until the runtime stack overflows. This is particularly risky when developers map Firestore document paths to handler logic dynamically, such as using path parameters to determine which documents to read next without validating depth or cycle conditions.

Consider an Actix handler that recursively fetches related documents by reading a parent_id field from each Firestore document. If a document references its own ancestor (or an attacker crafts a document chain that loops), the handler can enter infinite recursion. Because Actix processes requests on a multi-threaded runtime with limited stack space per thread, deep recursion exhausts the stack and crashes the request handling thread, leading to 5xx errors or process instability. This pattern is common when developers treat Firestore document trees as linked lists and traverse them with naive recursive functions instead of iterative approaches.

In this combination, the vulnerability is amplified by Firestore’s document-oriented model: each document can contain references to other documents, and resolving those references involves additional I/O and data parsing inside the Actix handler. If the handler uses recursive deserialization or recursive business logic that depends on document depth, an attacker can craft a chain of documents (e.g., a linked list of public posts pointing to parent posts) that triggers deep recursion. Because the scan tests input validation and unsafe consumption patterns, middleBrick would flag this as an input validation and unsafe consumption finding, noting the absence of depth limits or cycle detection when traversing Firestore document graphs.

Moreover, Actix routes that accept user-supplied identifiers and use them to query Firestore can inadvertently expose recursive traversal paths. For instance, an endpoint like /threads/{thread_id}/comments/{comment_id} might fetch a comment and then recursively fetch parent comments by reading Firestore documents in a loop that does not track visited nodes. Without explicit guards, this can lead to stack growth proportional to the depth of the comment tree. middleBrick’s checks for BFLA and property authorization would highlight that the handler does not enforce access controls or depth limits on the document traversal, increasing the risk of resource exhaustion via crafted document hierarchies.

To prevent stack overflow when integrating Firestore with Actix, replace recursive document traversal with an iterative approach using an explicit stack or queue. Track visited document IDs to detect cycles, and enforce a maximum depth for traversal. This ensures that the Actix handler’s call stack remains bounded regardless of the document graph shape.

use actix_web::{web, HttpResponse, Result};
use google_cloud_firestore::client::Client;
use std::collections::{HashSet, VecDeque};

async fn fetch_thread_comments(
    client: web::Data,
    path: web::Path<(String, String)>,
) -> Result {
    let (thread_id, start_comment_id) = path.into_inner();
    let mut visited = HashSet::new();
    let mut queue = VecDeque::new();
    queue.push_back(start_comment_id);
    let max_depth = 10;

    while let Some(comment_id) = queue.pop_front() {
        if visited.contains(&comment_id) {
            continue;
        }
        visited.insert(comment_id.clone());

        let doc_ref = client.collection("threads").doc(&thread_id).collection("comments").doc(&comment_id);
        let snapshot = doc_ref.get().await.map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
        let comment: Comment = snapshot.try_into().map_err(|e| actix_web::error::ErrorBadRequest(e))?;

        // If we haven't reached max depth, enqueue parent safely
        if max_depth > 0 && visited.len() < 1000 {
            if let Some(parent_id) = comment.parent_id {
                queue.push_back(parent_id);
            }
        }
    }
    Ok(HttpResponse::Ok().json(visited.len()))
}

This iterative pattern bounds stack usage because the recursion is managed on the heap via VecDeque. The handler limits traversal depth and tracks visited nodes to prevent cycles, addressing both input validation and property authorization concerns. By controlling how many documents are fetched and ensuring no unbounded recursion, the risk of stack exhaustion is eliminated.

Additionally, validate and sanitize all user-supp identifiers before using them in Firestore queries to prevent path traversal or injection that could lead to unintended document access or deep traversal. Apply middleware in Actix to enforce sane limits on document depth and to reject requests that would cause excessively deep traversals. middleBrick’s findings for BOLA/IDOR and input validation provide further guidance on securing the data flow between HTTP requests and Firestore document reads.

For API security management, use the CLI (middlebrick scan <url>) or the GitHub Action to integrate these checks into your CI/CD pipeline, ensuring that recursive traversal patterns are flagged before deployment. The dashboard can track the security score over time, while the MCP Server allows you to scan APIs directly from your AI coding assistant, catching recursion risks early in development.