Server Side Template Injection in Hapi (Javascript)

Server Side Template Injection (SSTI) in Hapi with JavaScript occurs when user-controlled data is embedded into a template without proper escaping or validation, allowing an attacker to inject template logic that executes on the server. Hapi does not include a built-in templating engine, but it is commonly paired with third-party engines such as Handlebars, Mustache, or custom rendering logic. When these engines are used unsafely—for example, by compiling user input as part of the template or by interpolating data into a template string without context-aware escaping—an attacker can break out of the intended data context and execute arbitrary template code.

Consider a route that merges request query parameters directly into a Handlebars template string and then renders it. If the template is compiled on each request with user-controlled input influencing the template structure, an attacker can supply payloads like {{this.constructor.constructor('return process')()}} in a vulnerable engine configuration to access Node.js internals. In JavaScript-based template engines, prototype pollution and sandbox escape techniques can lead to Remote Code Execution (RCE), sensitive data exposure, or denial of service. These issues align with the BOLA/IDOR and Property Authorization checks in middleBrick’s 12 security checks, which specifically look for unsafe data usage in templates and missing context-aware escaping.

Because SSTI leverages the dynamic nature of JavaScript and the flexibility of template engines, the attack surface includes not only direct template rendering but also any helper functions or partials that may be registered globally. An engine that allows arbitrary JavaScript execution through expressions or that does not enforce a strict allowlist of safe values can amplify the risk. middleBrick scans for these patterns by correlating OpenAPI/Swagger specifications with runtime behavior, identifying endpoints that accept input used in template contexts without adequate validation or encoding.

To remediate SSTI in Hapi with JavaScript, enforce strict separation between data and template structure. Never compile or render templates using user-controlled input as part of the template definition. Use context-aware escaping provided by the templating engine, and validate all inputs against an allowlist before they reach the rendering layer.

Example of a vulnerable pattern:

const Hapi = require('@hapi/hapi');
const Handlebars = require('handlebars');

const init = async () => {
  const server = Hapi.server({ port: 3000 });
  server.route({
    method: 'GET',
    path: '/greet',
    handler: (request, h) => {
      const name = request.query.name; // user-controlled
      const template = `Hello, ${name}!`; // unsafe interpolation
      const compiled = Handlebars.compile(template);
      return compiled({});
    }
  });
  await server.start();
};
init();

An attacker can supply ?name={{this.constructor.constructor('return process')()}} and, depending on the Handlebars configuration, potentially execute code. The fix is to treat user input strictly as data and avoid compiling templates derived from it.

Secure implementation using explicit data context and no dynamic template compilation:

const Hapi = require('@hapi/hapi');
const Handlebars = require('handlebars');

const safeTemplate = Handlebars.compile('Hello, {{name}}!');

const init = async () => {
  const server = Hapi.server({ port: 3000 });
  server.route({
    method: 'GET',
    path: '/greet',
    handler: (request, h) => {
      const name = request.query.name;
      // Validate input: allow only alphanumeric characters
      if (!/^[a-zA-Z0-9\s]+$/.test(name)) {
        return h.response('Invalid input').code(400);
      }
      return safeTemplate({ name });
    }
  });
  await server.start();
};
init();

In this secure version, the template is compiled once at startup with a trusted structure, and user input is treated strictly as data. Input validation ensures only expected values are passed to the rendering context. middleBrick’s checks for Input Validation and Data Exposure will flag the insecure pattern and confirm the secure implementation does not expose dangerous runtime behaviors.

Additionally, if your application uses partials or helpers, register them explicitly at initialization and avoid runtime registration based on user input. This reduces the risk of prototype pollution or unauthorized function execution within the template engine.