What is SSTI?

Server-Side Template Injection, or SSTI, affects applications that generate pages, messages or documents with a template engine. If untrusted input becomes part of the template source, an attacker can inject template expressions. The result ranges from reading variables to invoking functions and executing code on the server.

SSTI is different from Cross-Site Scripting. XSS executes in a visitor's browser; SSTI is evaluated by the server-side template engine. The exact syntax and impact depend on the engine and its sandbox.

How can SSTI be prevented?

• - Keep template source fixed and pass user content only as data variables.
• - Do not offer user-editable templates unless the feature is strongly isolated and deliberately designed for it.
• - Use sandboxing as an additional control, not as permission to evaluate arbitrary expressions.
• - Run rendering with minimal privileges and keep the template engine current.

Code example: separate template source from data

Vulnerable with Twig:

// User input becomes an executable template
$template = $twig->createTemplate($request->input('message'));
return $template->render(['user' => $user]);

Safe:

// notification.html.twig comes from the trusted deployment
return $twig->render('notification.html.twig', [
    'message' => $request->input('message'),
    'user' => $user,
]);

The template engine encodes the variable for its output context. If users genuinely need to design templates, provide a deliberately narrow expression language and isolation; a general production template engine is too powerful for this purpose.

Where is SSTI often found?

Common locations include email previews, document generators, custom notification text and applications that build templates through string concatenation. Error messages exposing the template engine often make exploitation easier.

SSTI or cross-site scripting?

With XSS, the browser interprets unsafe output as active content. With SSTI, the server evaluates the injected expression while rendering. A simple mathematical expression may initially produce only a changed number. If the expression can reach runtime objects, functions or classes, the result may be file access, internal requests or full code execution.

How is SSTI tested?

1. Identify input that appears in emails, PDFs, previews or dynamic templates.
2. Use harmless engine-specific expressions to determine whether the server evaluates rather than prints them.
3. Identify the engine and available context without changing files or data.
4. Limit the proof to the smallest statement about impact and reachable functionality.

Template engines use similar-looking syntax but interpret it differently. One failed payload does not exclude SSTI. Source review is particularly valuable: whenever user input becomes template source or reaches a “render from string” function, the trust boundary deserves close inspection.

Secure user-editable templates

If a product must offer customizable templates, it should expose a deliberately limited language with a small set of placeholders. Rendering runs in an isolated process without secrets, file-system access or unrestricted networking. CPU time, memory and output size are limited. A general template engine sandbox helps, but remains dependent on version and configuration and should not be the only security boundary.