Server-Side Template Injection (SSTI)

Server-Side Template Injection is sneakier than its cousins. SQLi takes you to the database, XSS takes you to the user's browser — SSTI usually takes you straight to a shell on the application server. It happens when developers reach for a template engine's flexibility (let users add a name to the email subject) and let user input cross the line from data to code.

Server-side template injection appears when user-controlled text is evaluated by a server template engine instead of being rendered as plain data. In severe cases, that can expose sensitive data or reach server-side execution paths.

Most template engines, by design, can call into the host language. That means SSTI typically grades up to remote code execution: arbitrary shell commands, file reads, lateral movement into adjacent services, or just a reverse shell. Even on engines with sandboxes (Handlebars, Mustache without helpers) the attacker can usually exfiltrate context variables that include secrets and session data.

Don't concatenate user input into templates. Pass user data as template variables, never as template source. If you must compose templates dynamically, use a sandboxed engine (Liquid is well-suited; Handlebars without runtime helpers is reasonable) and feed the user data as the data context only. As a second layer, run the rendering in a least-privileged process — separate Linux user, no shell, no network egress beyond what it needs. SSTI is one of the few classes where 'secure by construction' really applies — separate code from data and the entire family of bugs disappears.