How to fix Server-Side Template Injection (SSTI)

What an attacker can do

The concrete impact of leaving Server-Side Template Injection (SSTI) unpatched.

How to fix Server-Side Template Injection (SSTI)

5 ordered steps. Apply them in order — each builds on the previous.

1. 1

   Don't render user input AS templates — render it INTO templates

   Templates are code. User input is data. The fix is keeping them separate.

   If you currently have `template_str = 'Hello ' + user_input + ', welcome!'` and render it: STOP. Use `template = 'Hello {{ name }}, welcome!'` (constant) and pass `name=user_input` as a context variable.

   pythonStep 1

   # ❌ User input becomes part of template source — SSTI
   from jinja2 import Template
   template = Template(f"Hello {request.args.get('name')}, welcome!")
   output = template.render()
   # ?name={{config.__class__.__init__.__globals__['os'].popen('id').read()}}
   
   # ✅ Template is constant; user data passed as variable
   template = Template("Hello {{ name }}, welcome!")
   output = template.render(name=request.args.get("name"))
   # Now {{config...}} is rendered as the literal string, not evaluated

2. 2

   Use Jinja2 sandboxed environment if templates are user-supplied

   If users legitimately need to write templates (e.g., CMS users authoring email templates), use a sandboxed environment that blocks dangerous attribute access.

   `jinja2.sandbox.SandboxedEnvironment` blocks access to private attributes (`__class__`, `__bases__`). It's still bypass-able with effort, so combine with limiting available globals.

   pythonStep 2

   from jinja2.sandbox import SandboxedEnvironment
   
   env = SandboxedEnvironment(
       autoescape=True,
       finalize=lambda x: x if x is not None else "",
   )
   # Don't expose dangerous globals
   env.globals.clear()
   env.globals.update({"len": len, "range": range})  # only what's needed
   
   template = env.from_string(user_supplied_template_str)
   output = template.render(user_data)

3. 3

   Disable template execution on user-rendered output

   Frameworks often render template strings in error pages, flash messages, etc. Make sure those are escaped, not interpreted.

   Flask flash messages, Django messages framework, Rails flash[] — these are auto-escaped when rendered, but if you concat them into HTML before rendering, you bypass auto-escape.

   pythonStep 3

   # ❌ Flash message gets concatenated into another template
   flash(f"Hello {request.args.get('name')}")
   # Then {{ get_flashed_messages()[0] }} — escaped, but if you do:
   # flash(get_flashed_messages()[0])  # double-render trap
   
   # ✅ Always pass user data as variable, never concat into templates
   flash("Hello %s", request.args.get("name"))  # depends on framework

4. 4

   Use logic-less templates (Mustache, Handlebars without helpers)

   If you can choose your template engine, pick one without expression evaluation — Mustache deliberately doesn't have `if`/`for` with arbitrary expressions, removing most of the SSTI surface.

   Mustache's logic-less philosophy was specifically to avoid template-as-code coupling. For email templates and reports where you don't need full Turing completeness, Mustache is safer by design.

   javascriptStep 4

   // Handlebars with helpers — avoid arbitrary helper registration
   import Handlebars from "handlebars";
   
   // ❌ Don't allow user-controlled template strings
   const tpl = Handlebars.compile(userInput);
   
   // ✅ If templates must come from users (e.g. CMS authors),
   // use a strict allow-list of helpers and escape outputs
   Handlebars.registerHelper("safe-list", (arr) =>
     Array.isArray(arr) ? arr.map(String).join(", ") : "");
   
   // And consider switching to Mustache for user-authored templates

5. 5

   Run template rendering in a separate process with seccomp/AppArmor

   If you must run untrusted templates, isolate the renderer. Even sandbox bypasses become harmless if the process can't make syscalls or access the filesystem.

   Spawn a subprocess with seccomp filter blocking `execve`, `connect`, `open` (except for the template input). Use containers with `--read-only --network=none --cap-drop=ALL`.

   yamlStep 5

   # Docker for template-renderer service
   services:
     template-renderer:
       image: my-renderer
       read_only: true
       network_mode: none
       cap_drop: [ALL]
       security_opt:
         - no-new-privileges:true
         - seccomp=template-seccomp.json
       user: "65534:65534"  # nobody
       mem_limit: 128m
       cpus: 0.5