Header Injection in Actix with Mongodb

Header Injection in an Actix-web service that uses MongoDB occurs when user-controlled data is reflected into HTTP response headers without validation or encoding, and the backend persists or logs data into MongoDB in a way that can be leveraged. For example, an endpoint that accepts a X-Custom-User header to personalize content might store that value in a MongoDB document and later echo it into another response header. If the stored value contains newline characters (e.g., %0a or %0d), an attacker can inject additional headers, such as Set-Cookie or Location, leading to HTTP response splitting or cache poisoning.

In this combination, Actix routes receive requests and typically deserialize headers into Rust data structures or pass them directly to business logic that interacts with MongoDB. If input is accepted as-is and later used in header construction or stored in a MongoDB collection without sanitization, the boundary between data and control becomes blurred. Attack patterns like CRLF injection (\r\n) in header values can manipulate the response structure, causing the server to interpret injected lines as new headers or even a separate response. This can facilitate session fixation, cross-site scripting via injected headers, or bypass of security controls that rely on header integrity.

Moreover, if the Actix service uses MongoDB change streams or logs to monitor data changes, injected header content that is improperly sanitized could be written into MongoDB and later used in downstream contexts, such as reporting or admin interfaces. For instance, storing raw header values in a collection like requests and then displaying them in an administrative view can lead to stored XSS when the data is later rendered in a web UI, while the original injection occurred at the HTTP layer. The risk is compounded when the MongoDB document schema is permissive and does not enforce strict type or format validation on string fields that originate from headers.

Real-world attack vectors tied to this setup include using newline injection to set malicious cookies or to redirect users via a poisoned Location header. Consider an endpoint that records an API key in a custom header and persists it to MongoDB; an attacker could supply a key containing CRLF sequences to embed an additional Set-Cookie header, potentially setting a session cookie for a domain the attacker controls. Because the scan checks for Input Validation and Data Exposure, findings would highlight unsanitized reflection of headers into both responses and persistence layers, emphasizing the need to treat headers as untrusted input.

To mitigate Header Injection when using Actix with MongoDB, treat all incoming headers as untrusted and validate or transform them before using them in responses or storing them in the database. Below are concrete remediation steps and Rust code examples for an Actix service that interacts with MongoDB using the official MongoDB Rust driver.

First, sanitize header values before they are stored or echoed. Strip or reject carriage return and line feed characters to prevent CRLF injection. Here is an example of a helper function that cleans header values and a route that uses it:

use actix_web::{web, HttpResponse, Responder};
use mongodb::{Client, options::ClientOptions};
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
struct RequestRecord {
    id: mongodb::bson::oid::ObjectId,
    user_header: String,
}

fn sanitize_header(value: &str) -> String {
    value.replace("\r", "").replace("\n", "")
}

async fn record_header(
    header_value: web::Header<&str>,
    client: web::Data<Client>,
) -> impl Responder {
    let clean = sanitize_header(header_value.as_str());
    let doc = bson::doc! { "user_header": clean };
    let collection = client.database("appdb").collection("requests");
    let _ = collection.insert_one(doc, None).await;
    HttpResponse::Ok().body(format!("Recorded: {}", clean))
}

Second, enforce a strict schema in MongoDB and use server-side validation where possible to ensure stored header-like fields conform to expected formats. For example, define a JSON schema that rejects values containing newline characters and apply it at the collection level. If server-side validation is not feasible, enforce it in application code before insertion:

fn validate_header_format(value: &str) -> bool {
    !value.contains('\r') && !value.contains('\n') && !value.is_empty()
}

async fn validated_record(
    header_value: web::Header<String>,
    client: web::Data<Client>,
) -> HttpResponse {
    let raw = header_value.into_inner();
    if !validate_header_format(&raw) {
        return HttpResponse::BadRequest().body("Invalid header value");
    }
    let doc = bson::doc! { "user_header": raw.clone() };
    let collection = client.database("appdb").collection("requests");
    match collection.insert_one(doc, None).await {
        Ok(_) => HttpResponse::Ok().body(format!("Stored: {}", raw)),
        Err(e) => HttpResponse::InternalServerError().body(format!("DB error: {}", e)),
    }
}

Third, when constructing HTTP responses, avoid directly inserting user-supplied values into headers. Use framework utilities that enforce header safety or explicitly encode values. For example, setting a custom response header should involve sanitization and avoiding concatenation that could introduce control characters:

async fn safe_response(
    header_value: web::Header<String>,
) -> impl Responder {
    let raw = header_value.into_inner();
    let safe_value = sanitize_header(&raw);
    let mut resp = HttpResponse::Ok().finish();
    resp.headers_mut().insert(
        "X-Safe-User",
        safe_value.parse().unwrap_or_else(|_| "invalid".parse().unwrap()),
    );
    resp
}

Finally, combine these practices with the middleware capabilities of Actix to apply sanitization globally. This ensures that even if individual handlers forget to clean data, a centralized layer prevents CRLF-bearing values from reaching MongoDB or being reflected into headers. Regularly review stored documents and response behavior to confirm that header values remain within expected formats and that no unintended data exposure occurs.