Mobile backends generate a lot of text from templates: notification and email bodies, generated reports, server-rendered content, personalized messages. If any of that is built by inserting user input into the template itself, rather than passing the input as data into a fixed template, you may have server-side template injection. Template engines evaluate the syntax in the template, so an attacker who can get their input treated as part of the template can run that engine's expressions, often reaching from data disclosure all the way to executing code on your server. Here is what SSTI is, how it happens, and how to keep user input out of your templates.
Short answer
Server-side template injection (SSTI) is a vulnerability where user input is embedded into a server-side template that a template engine then evaluates, so an attacker can inject template syntax the engine executes. Per PortSwigger's research, the impact ranges from disclosing data and server internals to, in many engines, remote code execution, because template engines can evaluate expressions and reach objects and functions. It is relevant to mobile apps because their backends render templates, emails, notifications, reports, generated content, often using user-supplied values. The fix is to never construct a template from user input: pass user input as data into a fixed, predefined template rather than concatenating it into the template string, prefer logic-less or sandboxed templating, and keep the engine updated.
What you should know
- SSTI evaluates injected template syntax: input treated as part of the template.
- The impact can be code execution: not just data disclosure.
- Backends render templates: emails, notifications, reports, content.
- The flaw is input in the template: rather than passed as data.
- The fix is data, not template, construction: fixed templates with input as context.
What is SSTI?
It is injecting template-engine syntax through user input that gets evaluated as a template. Server-side template engines take a template, text with placeholders and logic, and render it by evaluating that logic and substituting values, producing the final output. The intended use is a fixed template with user data passed in as context, so the data fills placeholders but is never executed as template logic. SSTI happens when user input is instead incorporated into the template itself, for example by building the template string from input, so the engine evaluates the attacker's input as template syntax. Because template engines are powerful, their expressions can access objects, call methods, and in many cases reach the underlying runtime, an attacker who controls part of the template can do far more than alter output: they can read data and server internals and frequently execute code. The distinction that matters is between data and template: user input as data is safe, user input as part of the template is the vulnerability.
How does SSTI happen, and what is the impact?
It happens by mixing input into the template, and the impact escalates from there. The table outlines it.
| Step | What happens |
|---|---|
| Input built into the template | User input concatenated into the template string |
| Engine evaluates it | Template syntax in the input is executed |
| Expression evaluation | The attacker reads data or server internals |
| Object and method access | The engine reaches runtime objects |
| Remote code execution | In many engines, the attacker runs code |
SSTI typically arises when a developer builds a template dynamically by inserting user input into the template source, often to make content configurable, instead of passing the input as a rendering context. Once the engine renders that template, any template syntax in the input is evaluated, so an attacker probes by submitting template expressions and seeing them computed in the output. From there the impact depends on the engine, but it is often severe: many template engines expose objects, attributes, and methods that an attacker can navigate from within an expression, allowing them to read sensitive data and server configuration and, in a large number of engines, to reach functionality that runs arbitrary code on the server. That escalation from a configurable template to code execution is what makes SSTI dangerous, and it all follows from the input being part of the template rather than data fed to it.
How do you prevent SSTI?
Keep user input out of the template, and harden the engine. The decisive rule is to never construct a template from user input: define your templates statically in your code or template files, and pass user-supplied values in as data, the rendering context, so they fill placeholders and are never evaluated as template logic. If you find yourself building a template string by concatenating input, that is the bug, so restructure it to a fixed template with input as context. Avoid letting users supply or edit templates at all; if a feature genuinely needs user-provided templates, use a sandboxed or logic-less templating engine designed to restrict what templates can do, and treat it as a high-risk feature with strict limits, rather than a general-purpose engine that can reach the runtime. Validate and contextually encode user data as appropriate for where it appears in the output. Keep your template engine and its sandbox up to date, since sandbox escapes have been found and patched over time. The principle is the same as for other injection: separate code from data, here meaning the template is code you control and user input is only ever data passed into it, never part of the template itself.
What to watch out for
The first trap is building a template by concatenating user input, which lets the engine evaluate attacker-supplied template syntax; pass input as data into a fixed template. The second is offering user-editable templates with a powerful engine, which invites code execution; use a sandboxed or logic-less engine and strict limits. The third is assuming SSTI only discloses data, when many engines allow code execution. SSTI is a server-side flaw, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS, assesses the app's input handling and surfaces the endpoints that send data to your backend, while the template rendering and its safety are yours to implement server-side.
What to take away
- SSTI is when user input is embedded into a server-side template the engine evaluates, letting an attacker inject template syntax that often escalates from data disclosure to remote code execution.
- It affects mobile backends that render templates, emails, notifications, reports, content, when input is built into the template rather than passed as data.
- Prevent it by never constructing templates from user input, passing input as rendering data into fixed templates, avoiding user-editable templates or using a sandboxed logic-less engine, and keeping the engine updated.
- SSTI is server-side; use a pre-submission scan such as PTKD.com to assess input handling, and keep templates code-controlled with input as data on the backend.
