Server Side Template Injection in Rocket with Bearer Tokens

Server Side Template Injection (SSTI) in the Rocket framework occurs when user-controlled data is passed into a template engine and interpreted as logic or expressions. When endpoints protected with Bearer token authentication reflect or store token-derived values in rendered templates, the trust boundary between authentication and presentation can be violated. An attacker who influences template rendering through injected expressions may be able to read variables, call methods, or access runtime objects that expose sensitive information or behavior.

Consider a Rocket handler that authenticates via a Bearer token and then uses a value derived from claims (e.g., user role or tenant ID) inside a template. If the template is user-influenced or contains unsafe interpolation, an SSTI vector can emerge. For example, a claim such as sub or a custom claim could be concatenated into a string that becomes part of the template context. Rocket’s request guards ensure the token is present and valid, but they do not sanitize or isolate data used in templates. This means an authenticated request can still lead to template code execution if the application constructs dynamic templates or passes structured data into a rendering context that is not strictly typed and validated.

An attacker might supply a crafted Bearer token containing template syntax (e.g., a JWT with a manipulated payload) and observe whether the application reflects evaluated expressions in responses. In a scenario where endpoints consume token claims to build view models, unsanitized use of those claims in templates can disclose configuration details, local file paths, or environment variables. Because Rocket is type-safe at the handler level, developers may assume data from claims is inert; however, once it flows into a template engine that supports introspection or method calls, the risk of injection increases.

An example of a vulnerable pattern is building a context map from token claims and passing it directly to a Handlebars or Tera template without validation:

use rocket::State;
use rocket_dyn_templates::{context, Template};

#[get("/profile")]
fn profile(token_claims: Claims) -> Template {
    let ctx = context! {
        user: token_claims.sub,
        scope: token_claims.scope,
    };
    Template::render("profile", &ctx)
}

If the template profile.html.tera uses unchecked expressions like {{ user | safe }} or includes partials that evaluate further, an attacker who controls the token payload may inject logic such as {{ () }}.method() (in Tera) or helpers that read server-side variables. This combination of authenticated requests with dynamic template data creates a pathway for SSTI, where the attacker’s influence extends beyond authentication scope into the rendering layer.

Remediation focuses on strict separation between authentication-derived data and template rendering. Do not pass raw token claims directly into templates. Instead, project claims into explicitly typed, validated structures that only expose intended fields. Use serialization guards and avoid marking user-influenced content as safe.

First, define a dedicated view model that includes only the subset of data required for the template, and construct it manually rather than through automatic context macros:

use rocket::serde::json::Value;
use rocket_dyn_templates::Template;

#[derive(Serialize)]
struct ProfileView {
    username: String,
    tenant_id: String,
}

#[get("/profile")]
fn profile(claims: Claims) -> Template {
    let view = ProfileView {
        username: claims.sub.clone(),
        tenant_id: claims.tenant_id.clone(),
    };
    Template::render("profile", &view)
}

Second, enforce strict escaping in templates. In Tera, avoid the safe filter on any field derived from tokens. In Handlebars, ensure helpers do not allow arbitrary code execution. If you must include dynamic partials, validate the partial name against a whitelist rather than using token input to determine which template to load:

// Example guard before rendering a dynamic partial name
let allowed_partials = ["user_summary", "org_header"];
let requested_partial = claims.partial.as_str();
if allowed_partials.contains(&requested_partial) {
    Template::render("main", &context! { partial: requested_partial })
} else {
    // return a safe default or error
}

Third, validate and sanitize token payloads before use. Even though Bearer tokens are signed, their payload should be validated for expected format and constrained values. Use strong type conversions and reject tokens with unexpected claims that could alter template behavior:

use rocket::request::Request;
use rocket::Outcome;
use rocket::request::FromRequest;

struct Claims {
    sub: String,
    tenant_id: String,
}

#[rocket::async_trait]
impl<'r> FromRequest<'r> for Claims {
    type Error = ();

    async fn from_request(request: &'r Request<'_>) -> Outcome {
        // extract and validate token
        // ensure sub and tenant_id conform to expected patterns
        // reject tokens with extra or dangerous claims
    }
}

Finally, adopt defense-in-depth by scanning APIs for SSTI and authentication-related findings. Using middleBrick, you can detect misconfigurations where token-derived data reaches templates. The tool’s checks include authentication analysis and input validation, helping identify endpoints where Bearer token flows intersect with unsafe rendering. With the Pro plan, you can enable continuous monitoring so changes that reintroduce unsafe template data trigger alerts before deployment, and the GitHub Action can fail builds when risk thresholds are exceeded.