Server Side Template Injection in Rocket with Mutual Tls

Server Side Template Injection (SSTI) in the Rocket framework when combined with Mutual Transport Layer Security (mTLS) involves a specific interaction between request validation, identity verification, and template rendering. mTLS requires both the client and server to present valid certificates during the TLS handshake, which strongly authenticates the client before an HTTP request reaches the application layer. In Rocket, once a request is accepted, route handlers typically deserialize form data, JSON, or other inputs before passing values into templates. If user-controlled data flows into a template engine without proper escaping or strict context-aware sanitization, an attacker can inject template logic that executes on the server.

With mTLS in place, the perceived security boundary can create a false sense of safety. Because mTLS ensures the client possesses a trusted certificate, developers might assume all incoming data from that client is trustworthy. However, mTLS does not enforce content validation; it only confirms identity. A compromised or malicious certificate, a certificate issued to an unintended service, or a legitimate client whose credentials have been hijacked can still supply malicious template payloads. In Rocket, if a handler binds JSON or form fields directly to a template context (for example via tera or handlebars), an attacker who controls the certificate identity can still submit template injection payloads such as {{7*'7'}} or more complex expressions that read filesystem paths or invoke helpers.

The risk is particularly pronounced when Rocket routes expose sensitive operations—such as reading configuration or invoking internal services—through templates that do not enforce strict allowlists. An SSTI in this setting can lead to unauthorized file reads, remote code execution through unsafe helpers, or data exposure, even though the channel was protected by mTLS. Because mTLS terminates TLS early and hands identity information to the application, developers may inadvertently log or echo certificate details into templates, further expanding the attack surface. Proper input validation, output encoding, and strict separation between identity and data remain essential to prevent SSTI despite the presence of mTLS.

Remediation focuses on treating mTLS identity as metadata for auditing and access control, not as a guarantee of data safety. In Rocket, you should validate and sanitize all user-supplied inputs regardless of mTLS status, apply context-specific escaping in templates, and avoid injecting certificate fields directly into template contexts. Below are concrete code examples that demonstrate secure patterns.

Enabling mTLS in Rocket

Configure Rocket to require client certificates and validate them against a trusted CA. Use strong cipher suites and prefer recent TLS versions.

#[macro_use] extern crate rocket;
use rocket::tls::{Tls, CertificateVerification};

#[launch]
fn rocket() -> _ {
    rocket::build()
        .configure(rocket::Config {
            tls: Some(Tls {
                cert_chain: "/path/to/server.crt".to_string(),
                private_key: "/path/to/server.key".to_string(),
                client_ca: "/path/to/ca.crt".to_string(),
                client_verify: CertificateVerification::Required,
                ..Default::default()
            }),
            ..Default::default()
        })
        .mount("/", routes![index])
}

Safe Data Handling and Template Rendering

Ensure template inputs are validated, limited, and escaped. Do not directly embed raw request fields into templates.

use rocket::serde::json::Json;
use rocket::response::content::Html;
use validator::Validate;

#[derive(serde::Deserialize, Validate)]
struct UserInput {
    #[validate(length(min = 1, max = 100))]
    #[validate(regex(path = "crate::filters::ALPHANUM"))]
    name: String,
}

#[get("/greet")]
fn greet(form: rocket::form::Form) -> Result<Html, rocket::http::Status> {
    let data = form.into_inner();
    // Render with a context that contains only transformed, safe data
    let mut context = tera::Context::new();
    context.insert("name", &data.name);
    let rendered = TERATEMPLATES.render("greeting.html", &context)?;
    Ok(Html(rendered))
}

// A simple alphanumeric filter for Tera
mod filters {
    pub const ALPHANUM: &str = "^[A-Za-z0-9 ]+$";
}

// In templates (greeting.html), use autoescaping:
// <!-- greeting.html -->
<p>Hello {{ name | safe }}</p>

Auditing Without Template Pollution

Log mTLS identity for traceability, but do not merge certificate fields into template variables. Instead, pass identity as a separate, non-template channel for audit logs.

use rocket::request::Request;
use rocket::fairing::AdHoc;

fn audit_identity(rocket: Rocket<Build>) -> Rocket<Build> {
    rocket::ignite()
        .attach(AdHoc::on_request("Audit mTLS identity", |req, _| {
            if let Some(certs) = req.client_certs() {
                for cert in certs {
                    info!("mTLS identity: subject={}", cert.subject());
                    // Store in structured logs, not in request guards that reach templates
                }
            }
        }))
}

// Then mount routes as usual; templates receive only validated data

Template Engine Configuration

Use strict autoescaping and avoid custom helpers that bypass context checks. For Tera, enforce auto-escaping and avoid the safe filter unless absolutely necessary and carefully audited.

let mut t = tera::Tera::default();
t.set_escape_fn(|s| html_escape::encode_text_minimal(s).to_string());
// Prefer built-in escaping; do not mark user input as safe based on mTLS identity