Render User-Generated HTML Safely: Block Comment XSS Risks

40% of web application vulnerabilities trace back to XSS — and your rich text editor is the front door

The numbers don't lie: according to recent industry reports, cross-site scripting (XSS) consistently accounts for nearly 40% of all web application vulnerabilities. That's not a rounding error or a fringe statistic. It means if your application renders user-generated HTML strings, you're standing on the most contested battlefield in web security today.

I'm going to walk you through a scenario I see constantly in the developer tools space. You're building a collaborative document editor — think a Notion-style workspace or a markdown-powered knowledge base — and users need to paste formatted content, embed images, and share code snippets. The moment you decide to render that raw HTML string in the browser, you've opened a door that attackers love to walk through. By the end of this article, you'll have one workable sanitization pipeline that handles this safely without gutting your editor's functionality.

The scenario we're solving

Your users paste content from Word, Google Docs, and random websites. Your backend stores it as an HTML string. Your frontend needs to display it beautifully — bold text, tables, embedded images, the works. But between that paste event and the rendered DOM, there's a gap where a single <script> tag, an onerror handler, or a malicious href attribute can hijack user sessions, steal tokens, and compromise your entire application.

1 payload, 14 common vectors: understanding what you're up against

Let's get concrete. A typical XSS payload isn't just the obvious <script>alert(1)</script> that every tutorial warns you about. Security researchers have catalogued dozens of vectors that bypass naive string filtering. Here's a calculation worth remembering: if your sanitizer only strips <script> tags, you've closed exactly 1 of roughly 14 common attack vectors. The remaining 13 include:

• Event handler attributes: onload, onerror, onclick — these execute JavaScript without a single script tag
• JavaScript URIs: href="javascript:alert(document.cookie)" in anchor tags
• SVG-based payloads: embedded SVGs can carry inline scripts and foreign objects
• Data URIs: src="data:text/html,..." can execute script content
• CSS expression injection: legacy but still relevant in certain browser contexts
• Mutation XSS: payloads that exploit how browsers re-parse HTML after sanitization

The takeaway is simple: string replacement and regex-based filtering are fundamentally inadequate. You need a parser-based approach that understands the DOM, not just pattern matching.

Why regex sanitization fails at scale

I've seen developer teams attempt sanitization with regex patterns like /<script>.*?<\/script>/gi. The problem? Attackers craft inputs like <scr<script>ipt>alert(1)</script>. Your regex strips the inner <script> tag, the browser reassembles the remaining fragments, and the payload executes. One regex, zero protection. This is why parser-based sanitization libraries exist — they construct an actual DOM tree, evaluate each node, and discard anything that doesn't belong.

3 layers of defense: building a sanitization pipeline that actually works

Rather than relying on a single tool, a robust pipeline for safely rendering user-generated HTML strings operates in three distinct layers. Each layer catches what the previous one might miss, and together they reduce XSS risk to near zero.

Layer 1: Server-side sanitization with DOMPurify or sanitize-html

Your first checkpoint runs on the server before the HTML string ever reaches your database. This is non-negotiable. If you only sanitize on the client, an attacker can bypass your frontend entirely and POST raw malicious HTML directly to your API endpoint.

For Node.js backends, sanitize-html is a solid choice. For browser-side processing, DOMPurify is the industry standard — it's used by Facebook, Google, and Microsoft for good reason. Here's a practical configuration that balances security with the formatting your collaborative editor needs:

import DOMPurify from 'dompurify';

const config = {
  ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'u', 'a', 'ul', 'ol', 'li', 
                 'h1', 'h2', 'h3', 'h4', 'table', 'thead', 'tbody', 'tr', 
                 'th', 'td', 'img', 'code', 'pre', 'blockquote'],
  ALLOWED_ATTR: ['href', 'src', 'alt', 'title', 'class'],
  ALLOWED_URI_REGEXP: /^(?:(?:https?|mailto|data:image\/(?:png|jpeg|gif)):)/,
  FORBID_ATTR: ['style', 'onerror', 'onload', 'onclick']
};

const cleanHTML = DOMPurify.sanitize(userInput, config);

This configuration permits the formatting tags your editor needs while blocking inline styles (which can carry CSS-based attacks), JavaScript URIs, and all event handler attributes. The URI regex restricts links to HTTPS, mailto, and specific image data URIs — closing the javascript: vector entirely.

Layer 2: Content Security Policy as your safety net

Even with perfect sanitization, a Content Security Policy (CSP) provides critical defense-in-depth. If a sanitization bypass is discovered tomorrow — and they have been discovered in the past — your CSP prevents script execution regardless. The minimum viable CSP for an application rendering user HTML:

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'nonce-{random}';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  object-src 'none';
  base-uri 'none';

The object-src 'none' and base-uri 'none' directives alone eliminate entire classes of XSS vectors. The nonce-based script-src ensures only your explicitly tagged scripts execute. This is your safety net — it doesn't replace sanitization, but it catches what sanitization might miss.

Layer 3: Safe rendering in the framework

The final layer is how you actually inject the sanitized HTML string into the DOM. This is where framework-specific knowledge matters. Each major frontend framework handles HTML rendering differently, and using the wrong method can reintroduce XSS risk even after sanitization.

For React, use dangerouslySetInnerHTML — but only with sanitized content. The name is intentionally frightening. For Vue, use v-html with the same caveat. For Angular, use [innerHTML] with DomSanitizer. The key principle: never bypass these mechanisms, and never render sanitized HTML using document.write() or direct innerHTML assignment outside the framework's awareness.

0 false positives: tuning your sanitizer without breaking user content

A sanitizer that's too aggressive is almost as bad as no sanitizer at all. If users paste a table from Google Sheets and your sanitizer strips it, they'll find workarounds — and those workarounds are rarely secure. The goal is zero false positives: legitimate content passes through untouched, malicious content gets neutralized.

The calculation here is straightforward. Test your sanitization pipeline against two datasets: a corpus of known XSS payloads (the OWASP XSS Filter Evasion Cheat Sheet contains over 90 test cases) and a corpus of legitimate user content from your actual application. If your sanitizer blocks any legitimate content, adjust your allowed tags and attributes. If it passes any XSS payload, tighten your configuration.

Handling edge cases in collaborative editors

Collaborative document editors have a unique challenge: content changes in real-time as multiple users type. If you sanitize on every keystroke, you'll kill performance. If you sanitize only on save, you risk rendering unsanitized content during the editing session itself. The solution is a two-phase approach: sanitize aggressively on paste events (before content enters the editor's internal model), and sanitize again on persistence (before writing to the database). This gives you real-time editing performance without sacrificing security.

1 audit per quarter: maintaining your sanitization pipeline over time

Security isn't a set-it-and-forget-it task. DOMPurify has had bypasses discovered and patched. Browser parsing quirks change. New attack vectors emerge. A quarterly audit of your sanitization pipeline involves three steps: update your sanitization library to the latest version, re-run your XSS payload test suite, and review your allowed tags list against your current feature requirements. This takes roughly 2 hours per quarter and prevents the kind of vulnerability that can compromise every user in your application.

The bottom line for anyone building tools that render user-generated HTML: sanitization is not optional, it's not a checkbox, and it's not something you can handle with a regex. A parser-based sanitization library, a strict CSP, and framework-aware rendering — that's your pipeline. Three layers, near-zero XSS risk, and your collaborative editor stays both functional and secure.