---
{
  "title": "HTML sanitization",
  "summary": "HTML sanitization removes or rewrites unsafe markup while retaining approved formatting.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Cross Site Scripting Prevention",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

HTML sanitization removes or rewrites unsafe markup while retaining approved formatting. It is useful when an application intentionally accepts rich text and cannot display everything as plain text. A maintained sanitizer needs a policy for elements, attributes, URL schemes, and other browser features.

## A practical example

A knowledge base permits paragraphs and lists in contributor articles but removes event handlers and unsafe links. After sanitization, the publishing pipeline avoids transformations that could turn the approved output into executable markup again.

## What to check

Define the smallest formatting policy that meets the product requirement. Keep the sanitizer updated and test malformed markup, nested elements, and changes introduced by later rendering stages.

## A common pitfall

A regular expression that strips script tags is not an HTML parser and misses many executable browser contexts. Sanitized output can become unsafe if modified afterward.

## Think it through

Why review a formatter that runs after sanitization?

**Answer:** Its transformations may reintroduce dangerous markup, invalidating the sanitizer's earlier security decision.

## Rich text is a constrained language

A fictional publishing tool wants contributors to use headings, emphasis, and links. That requirement does not imply permission to supply every HTML feature a browser understands. A sanitizer policy defines the small formatting language the product actually supports. Product and security teams should agree on that language before implementation so forbidden features are deliberate rather than accidental breakage.

The processing sequence matters. Markdown conversion, HTML sanitization, link rewriting, and syntax highlighting can each change the output. If sanitization runs before a later transformation creates new HTML, the earlier decision may no longer describe what reaches the browser. Review the complete publishing pipeline, including preview and archived-content views.

Links deserve a separate decision. A link can be harmless to surrounding markup while still leading somewhere the application should not encourage. The permitted URL schemes and any destination restrictions belong in the formatting policy. Likewise, image support introduces questions about remote requests, privacy, and where the content is hosted. Sanitization is one part of the publishing design.

## Build a formatting contract

Write a small sample article containing every allowed feature: a heading, a list, emphasis, and an approved link. Add ordinary malformed markup and an unsupported element as test cases. State the expected rendered result in plain language. A contributor should know whether unsupported content is removed, converted to text, or rejected.

Keep original content only under appropriate access controls and avoid serving it directly through a bypass route. When the sanitizer library changes, compare representative saved articles and security regression cases. The aim is not to invent a perfect filter from regular expressions; it is to use a maintained parser-based tool with a narrow, tested policy that matches the final browser rendering path.

## Related concepts

- [[xss]]
- [[output-encoding]]