Server Side Template Injection in Actix with Bearer Tokens

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 server-side templates (for example with askama or similar engines), failing to properly escape user input allows an attacker to achieve arbitrary code execution within the template context. When Bearer Tokens are used for authentication, the risk pattern changes: developers sometimes pass the raw token or a derived value into the template context to build URLs, authorization headers, or audit logs. If that token value is directly interpolated without validation or escaping, an SSTI payload can manipulate token formatting or break out of the intended context, potentially exposing sensitive data or altering behavior.

Consider an endpoint that receives an authorization token via the Authorization header and forwards it to a template for diagnostic display or dynamic link generation. An attacker could supply a malicious token such as ${7*7} or a more advanced payload that triggers template evaluation, depending on the template engine’s syntax. In Actix, route handlers often deserialize headers, and if a developer does something like let token = req.headers().get(header::AUTHORIZATION) and then passes token.to_string() into a template, the token becomes part of the renderable data model. Because tokens are high-value secrets, an SSTI that can read or leak that value becomes particularly severe, as it may expose bearer credentials in logs or error pages.

The combination is dangerous because Bearer Tokens are often treated as opaque strings, leading developers to assume they are safe from injection. However, templates may perform string concatenation or conditional rendering based on token presence, and an attacker can probe for template context leaks via error messages or reflected content. For example, an unauthenticated scan by middleBrick can detect whether template errors reveal token structure or whether dynamic construction of URLs with tokens is reflected in responses. This can map to common OWASP API Top 10 items such as Broken Object Level Authorization when token handling intersects with IDOR or BOLA patterns.

In practice, you should treat any user-controlled or header-derived value entering a template as untrusted. This includes authorization tokens, query parameters, and custom headers. middleBrick’s unauthenticated black-box scans can surface indicators of insufficient input validation and data exposure when tokens are reflected or processed in templates, helping you identify risky code paths without requiring credentials.

Remediation focuses on strict separation of data and logic: never pass raw headers or tokens directly into templates. If you must include token-derived values, ensure they are treated as plain data, not executable template content. Use template engines that enforce context-aware escaping, validate and sanitize all inputs, and apply the principle of least privilege to token usage so that even if leakage occurs, the token scope is limited.

Secure Actix handlers should avoid placing Bearer Token values into contexts that are interpreted as template code. Below are concrete patterns that reduce risk while still allowing necessary token usage for downstream services or logging.

1) Avoid template interpolation of tokens entirely. Instead of passing the raw token to the template, pass a hashed or truncated representation if you need to display it for debugging, or omit it from the template and keep it server-side.

// Unsafe: directly injecting header value into template data
let token = req.headers().get(header::AUTHORIZATION)
    .and_then(|v| v.to_str().ok())
    .unwrap_or("");
let data = TemplateData { token: token.to_string() };
// Risk: token may be evaluated by the template engine

// Safer: do not include raw token in template model
let token_hash = hash_token(token); // e.g., SHA-256 truncated
let data = TemplateData { token_prefix: format!("{}...", &token_hash[..8]) };

2) Use strict request validation and extract tokens outside the rendering path. Validate the token format and scope before using it for business logic, and keep rendering minimal and data-only.

// Validate token structure early, then use it for authorization only
fn validate_bearer(token: &str) -> bool {
    token.starts_with("Bearer ") && token.len() > 7
}

async fn handler(req: HttpRequest, payload: web::Json) -> Result {
    let auth = req.headers().get(header::AUTHORIZATION)
        .and_toin_str()
        .ok_or_else(|| error::ErrorBadRequest("Invalid authorization header"))?;
    if !validate_bearer(auth) {
        return Err(error::ErrorUnauthorized("Invalid token"));
    }
    // Use token for backend call, not for rendering
    let client = req.app_data::()?;
    let resp = client.get("https://upstream.example.com/me")
        .bearer_auth(auth.trim_start_prefix("Bearer ").trim())
        .send()
        .await?;
    let body = resp.text().await?;
    let data = RenderData { username: extract_username(&body) };
    Ok(HttpResponse::Ok().content_type("text/html").body(render_template(&data)?))
}

3) If you must pass token-related metadata to a template, enforce context-aware escaping and use type-safe template APIs. For example, with askama you can mark fields that should remain plain text and rely on the compiler to prevent interpolation of executable logic.

#[derive(Template)]
#[template(path = "debug.html")]
struct DebugTemplate<'a> {
    token_hash: &'a str,
    // Never include raw token; use a sanitized representation
}

let token_hash = hex::encode(sha2::Sha256::digest(token.as_bytes()));
let tmpl = DebugTemplate { token_hash: &token_hash[..16] };
// In debug.html, use {{ token_hash }} which is auto-escaped by askama

4) Enforce rate limiting and monitoring around token usage to detect abuse patterns. Even with proper separation, high rates of invalid tokens may indicate probing for SSTI or brute-force attempts. middleBrick’s checks for Rate Limiting and Input Validation can surface such issues in scans, and the GitHub Action can gate merges if risky patterns are detected in code or configuration.

These patterns ensure Bearer Tokens remain opaque to templates and limit the impact of any potential injection surface. By combining code-level hygiene with automated scanning in CI/CD via middleBrick, you reduce the likelihood of token leakage and maintain clearer boundaries between authentication data and presentation logic.