XSS Prevention: Mastering Context-Aware Template Sanitization

We once spent three days chasing a persistent XSS bug in a legacy dashboard because a developer had explicitly disabled auto-escaping to "fix" a broken character entity. It turned out that a user-provided string was being injected directly into a JavaScript variable inside a <script> tag. The template engine did its job, but the developer bypassed it, creating a wide-open hole for attackers.

Understanding the Context-Aware Encoding Problem

Most modern template engines like EJS, Pug, or Twig provide auto-escaping by default. It’s easy to assume this makes you bulletproof. It doesn't. The browser interprets data differently depending on where it appears in the HTML document.

Injecting data into an href attribute requires different sanitization than injecting into a <div> inner text. If you treat all output as simple HTML text, you leave the door open for context-aware injection. When we discuss XSS prevention, we have to look past simple htmlspecialchars() or {{ variable }} tags and think about the DOM structure.

The Wrong Turn: Manual Sanitization

When we first tried to secure our templating layer, we manually regexed user input to strip <script> tags. It was a disaster. We missed encoded payloads, nested tags, and event handlers like onmouseover.

JAVASCRIPT
// Don't do this:
const clean = dirty.replace(/<script>/gi, ""); 
// Attackers can bypass this with <scr<script>ipt> or encoded payloads

Instead of fighting the browser, we shifted to using the built-in encoding features of our frameworks. For Node.js using EJS, we ensured that every variable was rendered using <%= %> (which escapes HTML) rather than <%- %> (which renders raw HTML). If you find yourself reaching for the raw tag, you’re almost certainly introducing a vulnerability.

Secure Rendering in Node.js and PHP

When handling Server-Side Template Injection, the goal is to keep the template logic and the user data strictly separated. In Node.js, we rely on EJS 3.x and Pug 3.x, which are context-aware enough to handle basic HTML injection. In PHP, Twig is the gold standard because it forces you to explicitly mark content as "safe" if you intend to bypass auto-escaping.

Here is how the comparison breaks down for standard rendering:

Implementing Defense-in-Depth

Even with perfect template sanitization, you need to be careful with JavaScript-embedded variables. If you’re passing data from your backend to a front-end script, do not just dump a JSON object into a <script> tag.

JAVASCRIPT
// Risky:
<script>
  const user = <%- JSON.stringify(userData) %>;
</script>

If userData.name contains </script><script>alert(1)</script>, the browser will break out of the block. We now use a helper that encodes the JSON object into a safe string format or, better yet, injects the data into a data-* attribute on an HTML element and retrieves it via dataset in our JavaScript entry point.

Avoiding Common Pitfalls

1. Don't bypass the engine: If you're using a filter or a "safe" tag, document exactly why. If you can't explain it in one sentence, you shouldn't be using it.
2. Watch your attributes: Always quote your attributes. <div class=<%= userClass %>> is vulnerable to space-delimited injection. Use <div class="<%= userClass %>"> instead.
3. Keep your libraries updated: We recently audited our dependencies and found an old version of a rendering library that had a known bypass for attribute injection. Use npm audit or composer audit regularly.

If you’re dealing with more complex data flows, remember that HTTP Parameter Pollution can also mess with the data hitting your templates. Ensure your input validation happens long before the data reaches the rendering stage.

I’m still not 100% satisfied with our current approach to complex client-side templating where we occasionally have to mix server-rendered content with dynamic React components. We’ve been experimenting with Content Security Policy (CSP) headers to act as a final safety net, but balancing strict policies with third-party tracking scripts is a constant headache. It’s a trade-off between absolute security and business requirements, and I’m not sure there’s ever a "finished" state.