Server Side Template Injection in Actix with Mongodb

Server Side Template Injection (SSTI) occurs when an attacker can inject template expressions that are evaluated on the server. In Actix web applications that render dynamic content using templating engines combined with MongoDB data sources, SSTI becomes a high-impact risk because injected template code can trigger unintended data access patterns or behavior before data reaches MongoDB.

Actix-web does not include a built-in template engine, but applications commonly integrate third-party engines such as Askama, Tera, or Handlebars. If user-controlled input is used to construct template variables or is passed into a template context without validation, an attacker may be able to inject template-specific syntax. For example, Tera supports filters and lookups; if a key is derived from user input, an attacker might use __lookup-style payloads to traverse object properties or invoke methods, depending on the engine’s capabilities.

When the rendered template is used to build a MongoDB query—such as embedding a field value directly into a BSON document or constructing a JSON-like selector—template injection can lead to query manipulation. Consider a scenario where a template produces a key path used in doc! { format!("${}.value", user_key) }. If user_key is influenced by template injection, an attacker could craft a key that traverses nested documents or introduces operators that alter query semantics when the document is later processed by application logic.

MongoDB itself does not interpret template syntax; the risk arises from the application using tainted template output to build queries, projections, or update documents. If the application deserializes user-controlled template fragments into BSON structures without strict schema validation, it may inadvertently expose sensitive fields or enable bypasses of intended access controls. For instance, an injected expression that resolves to a nested field like metadata.internal.debug could cause the application to include sensitive data in responses if the resulting query does not explicitly limit returned fields.

Operational impact includes unauthorized data exposure or changes in behavior, but the vulnerability is constrained by the application’s handling of templates and subsequent query construction. Because middleBrick performs black-box scanning without access to source code, it can detect indicators such as unusual data exposure patterns or missing input validation in API responses that suggest template-driven query anomalies when probing endpoints that integrate Actix and MongoDB.

Remediation centers on strict separation of template context and query construction, and rigorous validation of any data used to build MongoDB queries in Actix applications.

• Keep templates static and context minimal: Only pass simple, validated values into templates. Avoid passing raw user input that could contain template-like syntax.
• Validate and sanitize all inputs that influence query construction. Use allowlists for field names and enforce strict schema validation before converting user data into BSON.
• Use MongoDB’s official Rust driver types to construct queries explicitly, avoiding string interpolation for key paths.

Concrete code example: Safe query construction with validated input in Actix using the MongoDB Rust driver.

use mongodb::{bson::{doc, Document}, Collection};
use actix_web::{web, HttpResponse};

async fn get_user_profile(
    collection: web::Data,
    user_id: web::Path,
) -> HttpResponse {
    // Validate user_id format before using it
    let id = user_id.into_inner();
    if !id.chars().all(|c| c.is_ascii_alphanumeric() || c == '-') {
        return HttpResponse::BadRequest().body("Invalid user identifier");
    }

    // Build query using typed BSON, not string templates
    let filter = doc! { "_id": id };
    let projection = doc! { "profile": 1, "status": 1 };

    match collection.find_one(filter, Some(projection)).await {
        Ok(Some(doc)) => HttpResponse::Ok().json(doc),
        Ok(None) => HttpResponse::NotFound().body("Not found"),
        Err(e) => HttpResponse::InternalServerError().body(format!("Database error: {}", e)),
    }
}

If templates are required, ensure the rendering engine’s context is tightly controlled. For example, with Tera, avoid dynamic key lookups derived from user input:

// unsafe pattern to avoid:
// let user_supplied_key = ctx.get("key");
// let value = template.render(&user_supplied_key); // may traverse objects

// safe pattern:
let fixed_key = "public_name";
let value = template.render(fixed_key);

For applications using schema-based validation, integrate a validator that checks incoming JSON against a strict schema before constructing BSON documents. This ensures that only expected fields are used in queries and prevents injection-derived paths from affecting MongoDB operations.