Server Side Template Injection in Restify with Firestore

Server Side Template Injection (SSTI) occurs when an attacker can inject template syntax that is subsequently evaluated by a server-side templating engine. In a Restify service that builds responses using a template engine and queries Firestore, SSTI can arise if user-controlled data is embedded into templates without proper escaping or sandboxing. Restify does not include a built-in template engine, but many integrations use engines such as Handlebars, EJS, or Lodash to render dynamic responses that include Firestore documents.

Consider a scenario where a Restify handler fetches a Firestore document and passes it to a template. If the template includes user-influenced keys that are rendered without sanitization, an attacker may supply payloads that alter template behavior. For example, with Handlebars, an attacker might inject block parameters or path expressions that cause unintended property access or code execution when the template is compiled and rendered. The Firestore data itself may be benign, but the combination of a dynamic template engine and insufficient input validation allows the attacker to traverse object properties or invoke helpers that lead to Remote Code Execution (RCE) or sensitive data exposure.

An illustrative payload in a query parameter could look like {{this.__lookupGetter__('constructor').prototype.constructor('return process')()}} when the template engine does not properly restrict prototype pollution or function resolution. If Firestore documents are merged into the template context without sanitization, the attacker may leverage known gadget chains to execute arbitrary JavaScript. Real-world impact can include reading environment variables, exfiltrating Firestore documents, or executing commands on the host. The risk is compounded when the Restify service uses elevated service account permissions to access Firestore, potentially allowing broader lateral movement.

Because SSTI exploits the evaluation path of the template engine, the vulnerability is not in Firestore itself but in how data from Firestore is placed into the rendering context. Proper escaping, strict schema validation, and avoiding direct evaluation of user input within templates are essential. Tools like middleBrick can detect such issues by running checks for Input Validation and Unsafe Consumption, highlighting places where untrusted data reaches template rendering logic in APIs that integrate Restify and Firestore.

To remediate SSTI in a Restify service that uses Firestore, ensure that Firestore documents are never directly interpolated into templates and that all user input is validated and escaped. Use parameterized queries for Firestore reads and strict schema validation before passing data to the renderer. Below are concrete examples using the Firebase Admin SDK with Restify and a safe templating approach.

First, structure your Firestore access with strict data extraction rather than passing raw documents to templates:

const restify = require('restify');
const admin = require('firebase-admin');
admin.initializeApp();
const db = admin.firestore();

const server = restify.createServer();
server.use(restify.plugins.bodyParser());

server.get('/profile/:uid', async (req, res, next) => {
  try {
    const docRef = db.collection('users').doc(req.params.uid);
    const doc = await docRef.get();
    if (!doc.exists) {
      return res.send(404, { error: 'not_found' });
    }
    const data = doc.data();
    // Explicitly pick safe fields instead of passing the whole document
    const safeData = {
      displayName: typeof data?.displayName === 'string' ? data.displayName : '',
      email: typeof data?.email === 'string' ? data.email : '',
    };
    // Render using a function that escapes values
    const html = renderProfileSafe(safeData);
    res.setHeader('Content-Type', 'text/html');
    return res.send(html);
  } catch (err) {
    return next(new restify.InternalError('Internal error'));
  }
});

Second, implement a minimal escaping function for HTML contexts and avoid eval-like template engines. For example, using a simple escape routine:

function escapeHtml(str) {
  if (typeof str !== 'string') return '';
  return str.replace(/[<>"']/g, (s) => ({
    '&': '&',
    '<': '<',
    '>': '>',
    '"': '"',
    "'": ''',
  }[s]));
}

function renderProfileSafe(data) {
  return `
    <div>
      <h1>${escapeHtml(data.displayName)}</h1>
      <p>Email: ${escapeHtml(data.email)}</p>
    </div>
  `;
}

If you use a template engine, configure it to auto-escape and avoid custom helpers that allow code execution. For Handlebars, use the default escape behavior and do not register unsafe helpers:

const Handlebars = require('handlebars');
const safeTemplate = Handlebars.compile('<div>{{displayName}}</div>');
const output = safeTemplate({ displayName: escapeHtml(data.displayName) });

Additionally, apply principle of least privilege to the Firestore service account used by Restify, limiting read/write access to only required collections. Combine this with input validation libraries (e.g., Joi) to enforce schemas before database operations. middleBrick’s checks for Property Authorization and Input Validation can help surface insecure data flows between Firestore and rendering logic.