Token Leakage in Actix with Mongodb

Token leakage occurs when authentication tokens or session identifiers are inadvertently exposed in logs, error messages, or responses. In an Actix web service that uses MongoDB as a backend data store, the risk arises from the interaction between Actix's request handling and MongoDB operations. If application code embeds tokens—such as API keys, JWTs, or internal session identifiers—into documents stored in MongoDB or into log entries generated during database access, those tokens can be exposed through multiple channels.

One common scenario involves logging database activity without redacting sensitive fields. Actix handlers often log incoming requests and outgoing database queries for observability. If a MongoDB document contains a token in a field like api_token or refresh_token, and the application logs the full document or query result, the token is written to logs that may be accessible to unauthorized users or external systems. This expands the attack surface by making tokens discoverable through log aggregation services or compromised log stores.

Another vector is error handling. When Actix routes interact with MongoDB using drivers that return detailed errors, developers might inadvertently include raw query results or database metadata in HTTP error responses. For example, if a token is stored in a MongoDB document and an error occurs during a find operation, the driver might include partial document data in the error message. If the Actix handler forwards this error to the client, the token can leak in an HTTP response body or header. This pattern is relevant to common web vulnerabilities such as Sensitive Data Exposure (OWASP API Top 10) and can be surfaced by middleBrick’s Data Exposure and Input Validation checks.

With unauthenticated scanning, middleBrick can detect instances where token-like strings appear in HTTP responses or documentation examples that reference MongoDB integration. The LLM/AI Security checks specifically look for system prompt leakage and output containing API keys or tokens, which is valuable when assessing endpoints that interact with backend stores like MongoDB. By correlating runtime responses with OpenAPI specs, middleBrick can highlight endpoints where token leakage risks are likely due to improper data handling between Actix and MongoDB.

Real-world attack patterns mirror these risks. For instance, if an Actix endpoint returns user profile data that includes a MongoDB document with a token field, an authenticated attacker with limited access could extract another user’s token if authorization boundaries are not enforced (BOLA/IDOR). This intersects with Privilege Escalation where excessive permissions allow broader database reads. Using middleBrick’s BOLA/IDOR and Property Authorization checks can help identify endpoints where tokens are exposed due to missing ownership validation.

To prevent token leakage in Actix applications using MongoDB, apply targeted coding practices that avoid exposing sensitive fields in logs, errors, and responses. Below are concrete remediation strategies with realistic Rust code examples tailored for Actix and the MongoDB Rust driver.

First, sanitize data before logging. Avoid logging entire MongoDB documents. Instead, explicitly select non-sensitive fields for logging purposes. For example, when querying a user collection, log only identifiers and metadata, excluding token fields.

// Actix handler with safe logging
use actix_web::{get, web, HttpResponse};
use mongodb::{bson::doc, options::FindOptions};

#[get("/users/{user_id}")]
async fn get_user(
    user_id: web::Path,
    db: web::Data<mongodb::Database>
) -> actix_web::Result<HttpResponse> {
    let collection = db.collection("users");
    let filter = doc! { "_id": &*user_id };
    let opts = FindOptions::builder().projection(doc! { "username": 1, "email": 1 }).build();
    let result = collection.find_one(filter, opts).await;

    match result {
        Ok(Some(doc)) => {
            // Log only safe fields
            println!("User fetched: username={}, email={}", 
                doc.get_str("username").unwrap_or("unknown"),
                doc.get_str("email").unwrap_or("unknown")
            );
            let response = serde_json::json!({
                "username": doc.get_str("username").unwrap_or(""),
                "email": doc.get_str("email").unwrap_or("")
            });
            Ok(HttpResponse::Ok().json(response))
        }
        Ok(None) => Ok(HttpResponse::NotFound().finish()),
        Err(e) => {
            // Log error without exposing sensitive context
            eprintln!("Database error: {}", e);
            Ok(HttpResponse::InternalServerError().finish())
        }
    }
}

// Define a response DTO that omits token fields
use serde::Serialize;

#[derive(Serialize)]
struct UserPublic {
    username: String,
    email: String,
}

// Convert MongoDB document to safe DTO
fn to_public_user(doc: &mongodb::bson::Document) -> Option<UserPublic> {
    Some(UserPublic {
        username: doc.get_str("username").ok()?.to_string(),
        email: doc.get_str("email").ok()?.to_string(),
    })
}

// Safe error mapping in Actix
async fn safe_find_one(
    collection: &mongodb::Collection<mongodb::bson::Document>,
    filter: mongodb::bson::Document,
) -> Result<mongodb::bson::Document, actix_web::Error> {
    collection
        .find_one(filter, None)
        .await
        .map_err(|e| {
            eprintln!("Detailed error: {}", e); // server-side log
            actix_web::error::ErrorInternalServerError("Internal error")
        })
}