Input Sanitization

Problem

There are many more ways in than raw <script> tags. A comment containing <img src=x onerror="fetch('/api/transfer?to=attacker')"> runs JavaScript the moment the broken image fails to load. A profile bio with <a href="javascript:steal()">click me</a> makes an innocent-looking link run code when someone clicks it. Event handler attributes like onclick and onload get scripts past a filter that only looks for the word “script,” and SVG and <iframe> elements each have their own ways of running code. Attackers come up with new variations faster than a deny-list of “known bad” strings can keep up with them.

Injection isn’t limited to the browser, either. The same untrusted name that breaks your page can break your database when it goes into a query unescaped as '; DROP TABLE users;--, and unclosed or deeply nested tags can corrupt your layout or hang the renderer. In each case, you accepted data from someone you don’t control and passed it to an interpreter, such as the HTML parser or the SQL engine, that runs whatever it’s given.

Solution

For plain text, the simplest and safest approach is to never parse it as HTML at all. Setting textContent, or rendering through your framework’s default text binding, makes the browser treat input as literal characters, so <script> shows up on screen as text instead of running. If you need a string of escaped HTML, you can convert the dangerous characters yourself, with < becoming <, > becoming >, & becoming &, " becoming ", and ' becoming '.

If the feature requires rich text, such as a comment editor or a markdown preview, a maintained sanitizer like DOMPurify is a much safer choice than a regex you write yourself, because regex-based HTML filtering is easy to bypass. DOMPurify parses the input into a DOM, checks it against an allow-list of safe tags and attributes, and strips dangerous elements such as <script> and <iframe>, along with handlers like onerror and onclick and javascript: URLs. The result is markup that’s safe to render.

Beyond that, you should sanitize untrusted data at the boundary where it enters your app, and validate formats against schemas or precise patterns. Database queries should be parameterized instead of built by joining strings together. A Content Security Policy (CSP) header adds another layer of protection on top, because a strict CSP that forbids inline scripts can block an XSS payload even if a bug in your sanitization lets it through.

Example

These examples sanitize untrusted HTML before rendering it. The code is different in each framework, because each one has its own way to render raw HTML, and the sanitizer has to run before it.

Sanitizing Rich Text Before Rendering

import DOMPurify from 'dompurify';

function Comment({ html }) {
  // Sanitize untrusted HTML, then opt in to raw rendering.
  const clean = DOMPurify.sanitize(html, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'ul', 'ol', 'li'],
    ALLOWED_ATTR: ['href']
  });

  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}

<script setup>
import { computed } from 'vue';
import DOMPurify from 'dompurify';

const props = defineProps({ html: String });

// Sanitize before binding with v-html, never bind raw input.
const clean = computed(() =>
  DOMPurify.sanitize(props.html, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'ul', 'ol', 'li'],
    ALLOWED_ATTR: ['href']
  })
);
</script>

<template>
  <div v-html="clean" />
</template>

<script>
  import DOMPurify from 'dompurify';

  let { html = '' } = $props();

  // {@html} renders raw markup, so sanitize first.
  let clean = $derived(DOMPurify.sanitize(html, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'ul', 'ol', 'li'],
    ALLOWED_ATTR: ['href']
  }));
</script>

<div>{@html clean}</div>

import DOMPurify from 'dompurify';

class UserComment extends HTMLElement {
  set html(value) {
    // Sanitize untrusted markup before assigning to innerHTML.
    this.innerHTML = DOMPurify.sanitize(value, {
      ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'ul', 'ol', 'li'],
      ALLOWED_ATTR: ['href']
    });
  }
}

customElements.define('user-comment', UserComment);

Escaping HTML Without a Library

If you only need plain text rendered safely, the browser can do the escaping for you. Assigning the input to textContent and then reading back innerHTML makes the browser convert <, >, and & into entities without parsing the input as markup. Quotes come back unchanged, so the result is safe as text inside an element, but it isn’t safe inside an attribute value.

function escapeHTML(input) {
  const el = document.createElement('div');
  // textContent treats input as literal text; innerHTML escapes < > & (not quotes).
  el.textContent = input;
  return el.innerHTML;
}

escapeHTML('<img src=x onerror=alert(1)>');
// => "&lt;img src=x onerror=alert(1)&gt;"  (inert text, never executes)

Validating Formats With an Allow-List

You can reject malformed input at the boundary instead of cleaning it. This check compares each value against a strict pattern of permitted characters, and throws an error for anything that doesn’t match.

const RULES = {
  username: /^[a-zA-Z0-9_-]{3,20}$/,
  email: /^[^\s@]+@[^\s@]+\.[^\s@]+$/
};

function validate(field, value) {
  const pattern = RULES[field];
  if (!pattern || !pattern.test(value)) {
    throw new Error(`Invalid ${field}`);
  }
  return value;
}

validate('username', 'jane_doe-42');         // ok
validate('username', '<script>alert(1)</script>'); // throws: Invalid username

Summary

Input sanitization protects your app from injection by cleaning untrusted data where it enters, using allow-lists instead of deny-lists. You escape the HTML characters in plain text, and you use a maintained sanitizer like DOMPurify for rich text instead of writing a regex. Sanitization is one layer of protection, alongside format validation, parameterized queries, output encoding, and a strict Content Security Policy, and the same checks need to run on the server as well as on the client.