Nosql Injection in Actix with Basic Auth

When an Actix-web service uses Basic Authentication but continues to build NoSQL queries by directly interpolating user input, the authentication boundary does not protect the query logic. Basic Auth can provide a per-request identity for logging and authorization checks, but if the handler constructs a database query by concatenating or parsing untrusted parameters (e.g., JSON filters, URL query strings, or header-derived values), the credentials do not sanitize those inputs. This creates a scenario where an authenticated or unauthenticated attacker can inject into the NoSQL query structure, bypassing intended access controls or retrieving unintended data.

Consider a user profile lookup implemented in Actix with a MongoDB backend. If the handler reads a JSON filter like { "username": "{user_supplied}" } and embeds it into the query without validation, the injection can change the semantics of the lookup. For example, an input such as { "$ne": "" } could be interpreted as a JSON operator, causing the query to return records other than the intended user. In a REST endpoint that also uses Basic Auth for session-like identification, an attacker might supply a crafted Authorization header to observe behavioral differences or error messages that reveal whether injection is occurring. While Basic Auth itself is not the injection vector, its presence can lead developers to assume the request identity has been verified, reducing scrutiny on how parameters are combined into the query.

Actix-web routes often parse JSON bodies or form data into structs using serde. If the deserialization logic is too permissive or the handler merges user input into a raw BSON document without validation, the application remains vulnerable. Attack patterns include boolean-based blind injection to infer schema, field enumeration via operator injection, or using $where or aggregation pipeline stages when the database permits them. The risk is particularly acute when the API exposes filtering or search functionality that builds dynamic queries from user-controlled JSON fragments. Because the scan categories include Input Validation and Unsafe Consumption, middleBrick would flag unsafe query construction and lack of strict schema enforcement as findings, noting that authentication does not equate to input sanitization.

Another relevant scenario involves HTTP headers that are treated as query inputs. For instance, an Actix handler might read a custom header and merge it into a NoSQL filter. If Basic Auth is used for coarse-grained access control but the header value is directly concatenated into the query, an attacker can probe for injection by manipulating the header. The presence of Basic Auth may also encourage insecure deserialization practices, such as trusting parsed JSON structures because the request is considered authenticated. Effective mitigation requires strict schema validation, allowlisting of fields and operators, and avoiding the direct inclusion of untrusted data in query construction, regardless of the authentication mechanism in place.

To reduce risk, treat Basic Auth as an identity assertion rather than an input sanitization mechanism. In Actix, validate and sanitize all user-controlled data before it reaches the database layer, and enforce strict schema rules for JSON and BSON inputs. The following examples illustrate a secure approach.

Secure handler with strict deserialization and no dynamic injection

use actix_web::{web, HttpResponse, Result};
use serde::{Deserialize, Serialize};

#[derive(Deserialize, Serialize)]
struct ProfileRequest {
    username: String,
    // other allowed fields
}

async fn get_profile(
    credentials: actix_http::header::Authorization,
    body: web::Json,
) -> Result {
    // credentials.user_id() can be used for audit logging
    let user = &body.username;

    // Validate: alphanumeric with length limits, no control characters
    if !user.chars().all(|c| c.is_ascii_alphanumeric() || c == '_' || c == '-') {
        return Ok(HttpResponse::BadRequest().body("Invalid username format"));
    }
    if user.len() < 3 || user.len() > 64 {
        return Ok(HttpResponse::BadRequest().body("Username length out of range"));
    }

    // Build query using strongly-typed parameters, not raw JSON concatenation
    let filter_doc = bson::doc! {
        "username": user,
    };

    // database_operation(filter_doc).await; // use a safe data access layer
    Ok(HttpResponse::Ok().json(serde_json::json!({ "status": "ok" })))
}

Rejecting unsafe operators and dynamic keys

use actix_web::web;
use bson::{doc, Document};

fn build_safe_filter(params: &web::Json) -> Result {
    // Only allow known fields and explicit equality checks
    let obj = params.as_object().ok_or("Expected JSON object")?;
    let mut filter = Document::new();
    for (key, value) in obj.iter() {
        match key.as_str() {
            "status" | "role" => {
                if value.is_string() {
                    filter.insert(key.clone(), value.as_str().unwrap());
                } else {
                    return Err("Field must be a string");
                }
            }
            _ => return Err("Unsupported filter field"),
        }
    }
    Ok(filter)
}

Actix middleware or guard for authentication and input normalization

use actix_web::dev::ServiceRequest;
use actix_web::Error;
use actix_web_httpauth::extractors::basic::BasicAuth;

struct AuthenticatedRequest {
    user: String,
    // other identity fields
}

fn validate_request(req: ServiceRequest) -> Result {
    // Perform Basic Auth verification via a validator or service
    // On success, construct a normalized request object that carries identity
    // but does not forward raw user input into query construction
    unimplemented!("Implement auth validation and request normalization")
}

Key practices include using strongly typed structs for deserialization, whitelisting allowed fields and operators, avoiding direct document merging from untrusted JSON, and logging identity for audit without letting it influence query construction. middleBrick can detect insecure query building and missing input validation through its checks for Input Validation and Unsafe Consumption, helping teams identify these patterns even when Basic Auth is in use.