Server Side Template Injection in Loopback

Server Side Template Injection (SSTI) in Loopback typically arises when user-controlled input is passed into a server-side template helper or partial without validation or sanitization. Loopback applications that use dynamic view rendering via res.render() can become vulnerable if template logic is constructed from request data. For example, an attacker may control a query parameter that influences which partial is rendered, or a locale string that changes path concatenation in view engines like Pug or EJS.

Attack patterns specific to Loopback include abusing view paths to load templates from attacker-controlled locations, or injecting template directives that cause remote code execution via the underlying engine. In Pug, an input such as ${userInput} injected into a template that is later evaluated can lead to arbitrary JavaScript execution. A concrete scenario is a reporting endpoint where a user specifies a reportName that maps to a Pug file; if unsanitized, an attacker can provide a name like ../../../../etc/passwd or inject Pug syntax such as - return process.env to execute code.

Loopback’s REST API explorer and dynamic model endpoints can expose parameters that flow into server-rendered views. If an endpoint accepts a template or layout parameter that determines which view engine partial to use, and that value is not strictly enumerated or validated, SSTI becomes feasible. Additionally, custom helpers registered in Loopback’s view engine that reflect user input into evaluation contexts can introduce injection vectors. For instance, registering a helper that concatenates user strings into a new Function body enables execution of attacker-supplied JavaScript when the helper is invoked during rendering.

Detecting SSTI in Loopback requires analyzing how user input influences view resolution and template evaluation. You should review controllers and datasources for direct use of request parameters in res.render() calls, and audit any custom view helpers. middleBrick scans for SSTI by submitting probe payloads that attempt to inject template directives and observe whether execution results in unintended behavior, such as environment leakage or code execution indicators.

When scanning a Loopback API with middleBrick, the LLM/AI Security checks complement traditional SSTI detection by testing for prompt injection and output leakage that could indicate template engine manipulation. The scanner inspects OpenAPI specs, resolves $ref pointers, and correlates runtime behavior with defined routes to identify endpoints where unauthenticated input reaches rendering logic. For example, a route defined as POST /reports/:name that passes req.params.name into a view without validation would be flagged if the spec allows open-ended path parameters.

Example middleware inspection in a Loopback application:

app.use((req, res, next) => {
  // Risk: user input used to select view without validation
  const templateName = req.query.template || 'default';
  res.render(templateName, { data: req.query.data });
});

middleBrick’s dashboard provides per-category breakdowns, highlighting SSTI under Input Validation and Server-Side Logic checks, with severity and remediation guidance mapped to OWASP API Top 10 and related frameworks.

Remediation focuses on strict input validation, avoiding dynamic template selection, and sanitizing any user data that reaches template helpers. Use enumerated values for template or partial names, and leverage Loopback’s built-in validation rules to constrain parameters.

Instead of directly rendering user-supplied template names, define a whitelist and resolve paths server-side. For Pug templates, ensure dynamic includes are pre-resolved to known safe files:

const allowedTemplates = ['report-a', 'report-b', 'summary'];
app.get('/render', (req, res) => {
  const template = allowedTemplates.includes(req.query.t) ? req.query.t : 'default';
  // Safe: template is constrained to known files
  res.render(`reports/${template}`, { data: req.query.data });
});

If you use custom view helpers, avoid constructing functions from user input. Prefer static helper implementations that do not evaluate strings as code:

const loopback = require('loopback');
const app = loopback();
app.set('view engine', 'pug');
app.engine('pug', require('pug').__express);

// Safe helper that does not evaluate user input
app.locals.safeFormat = function(value) {
  return value.replace(/&/g, '&').replace(/