Insecure Direct Object Reference in Actix with Firestore

Insecure Direct Object Reference (BOLA/IDOR) occurs when an API exposes internal object references such as Firestore document IDs in URLs without verifying that the requesting user has permission to access them. In an Actix web service that uses Firestore as the backend, this often manifests as endpoints like /users/{user_id}/profile where {user_id} is taken directly from the route and used to read or write a Firestore document without confirming the authenticated caller owns that ID.

When Firestore security rules rely only on request authentication and do not enforce ownership checks tied to the authenticated UID, an attacker can enumerate or manipulate IDs to access or modify other users' data. For example, an authenticated user might change the user_id in the URL to another valid document ID and perform a GET or PATCH request. If the Actix handler passes that ID directly to Firestore without validating that the authenticated subject matches the document’s owner, the request succeeds and data is exposed or altered.

Actix routes typically bind path parameters to handler arguments. If the handler uses these parameters to build Firestore document paths like users/{user_id} and performs read/write operations without cross-checking the authenticated identity, the application treats user-supplied IDs as trusted references. Firestore’s permission model is rule-based; if rules are permissive or do not include a condition like request.auth.uid == request.resource.id (or a field within the document), the combination of Actix routing and Firestore access becomes vulnerable to IDOR.

Additionally, Firestore document IDs can be predictable (e.g., auto-generated but sequentially related IDs or known UIDs). Predictable references increase the risk of enumeration. Even when Firestore rules restrict reads to a user’s own collection, a missing ownership check in the Actix handler can still allow horizontal privilege escalation if the handler does not compare the authenticated UID to the requested resource ID before issuing the read or write operation.

An operational factor in such setups is that Firestore indexes fields efficiently, so queries that filter by owner UID are fast; however, if the application layer does not enforce the same filter, the API surface remains exposed. For example, an endpoint that should only show the current user’s tasks might query Firestore with a missing or incomplete filter, returning data belonging to other users when a direct document ID is supplied in the URL.

In summary, the vulnerability arises when Actix routes expose Firestore document identifiers without enforcing strict ownership validation on each request. Relying solely on Firestore rules without corresponding application-level checks, and failing to bind the authenticated subject to the requested resource, creates an IDOR path that allows unauthorized access or modification of data through predictable or enumerable object references.

Remediation centers on ensuring every Firestore operation in an Actix handler ties the requested resource to the authenticated user’s identity. Do not trust route parameters as the sole source of the document ID or ownership. Instead, derive or verify the document path using the authenticated UID, and enforce checks before any Firestore call.

Use the Firebase Admin SDK or an authenticated Firestore client within your Actix application to construct document references safely. Below are concrete examples for Actix handlers that implement proper ownership checks.

Example 1: Safe user profile retrieval

Instead of using the route-supplied user_id directly, bind the authenticated UID from the request’s identity and construct the document path from it.

use actix_web::{web, HttpResponse, Error};
use firebase_admin_rs::FirebaseApp; // hypothetical Admin SDK wrapper

async fn get_profile(
    req: actix_web::HttpRequest,
    path: web::Path<(String,)>, // (user_id_from_route)
    app: web::Data<FirebaseApp>,
) -> Result<HttpResponse, Error> {
    // Obtain authenticated UID from request extensions (e.g., via guard/validator)
    let auth_uid = req.extensions().get::()
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Missing authentication"))?;

    // Route-supplied user_id is ignored for ownership; we use the authenticated UID
    let document_path = format!("users/{}/profile", auth_uid);
    let doc_ref = app.firestore().doc(&document_path);
    let snapshot = doc_ref.get().await.map_err(|e| actix_web::error::ErrorInternalServerError(e))?;

    if snapshot.exists() {
        let profile: serde_json::Value = snapshot.deserialize()?;
        Ok(HttpResponse::Ok().json(profile))
    } else {
        Ok(HttpResponse::NotFound().finish())
    }
}

Example 2: Updating a user’s own settings with validation

Ensure the document being updated belongs to the authenticated subject, and validate input before the write.

use actix_web::web;
use serde_json::json;

async fn update_settings(
    req: actix_web::HttpRequest,
    payload: web::Json<serde_json::Value>,
    app: web::Data<FirebaseApp>,
) -> Result<HttpResponse, actix_web::Error> {
    let auth_uid = req.extensions().get::()
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Missing authentication"))?;

    // Build the document reference from the authenticated UID, not from user input
    let doc_ref = app.firestore().doc(&format!("users/{}/settings", auth_uid));

    // Optional: ensure the document exists before updating
    let exists = doc_ref.exists().await.map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
    if !exists {
        return Ok(HttpResponse::NotFound().json(json!({ "error": "settings not found" })));
    }

    // Perform update using server-side filtered data
    doc_ref.update(payload.into_inner()).await
        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;

    Ok(HttpResponse::Ok().json(json!({ "status": "updated" })))
}

Example 3: Querying user-owned resources safely

When listing resources, scope the query by the authenticated UID and avoid allowing the client to dictate document IDs in query parameters.

async fn list_user_tasks(
    req: actix_web::HttpRequest,
    app: web::Data<FirebaseApp>,
) -> Result<HttpResponse, actix_web::Error> {
    let auth_uid = req.extensions().get::()
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Missing authentication"))?;

    // Query scoped to the authenticated user; do not allow arbitrary filters that could bypass ownership
    let coll_ref = app.firestore().collection(&format!("users/{}/tasks", auth_uid));
    let tasks = coll_ref.list().await.map_err(|e| actix_web::error::ErrorInternalServerError(e))?;

    let items: Vec<serde_json::Value> = tasks.into_iter().filter_map(|doc| doc.deserialize().ok()).collect();
    Ok(HttpResponse::Ok().json(json!({ "tasks": items })))
}

Key remediation practices for Actix with Firestore:

• Derive document paths from the authenticated UID, not from route or query parameters.
• Validate that the authenticated subject matches the resource owner before any read, write, or delete operation.
• Use Firestore queries scoped to the owner UID instead of fetching by a user-controlled ID.
• Avoid exposing internal Firestore document IDs in URLs; if necessary, map them to opaque references server-side and re-validate ownership on each request.
• Leverage Firestore security rules as a secondary layer, but enforce ownership checks in application code to ensure defense in depth.