A Django product-review page renders {{ review.body|safe }} so that line breaks display; why is that an XSS hole, and how do you fix it?

## The bug A reviewer writes a multi-paragraph review. Rendered with `{{ review.body }}`, the newlines collapse into one line, so someone adds `|safe` hoping the text will format. It does not add any formatting, and it does something much worse: ```django <div class="review-body">{{ review.body|safe }}</div> ``` `safe` is implemented as `mark_safe(value)`. The value becomes a `SafeString`, the autoescaping pass skips it, and whatever the reviewer typed is written into the page as HTML. A body of `<img src=x onerror="fetch('/steal?c='+document.cookie)">` now runs in every visitor's browser, on a page the site serves as its own. Because the payload is stored in the database, one malicious review attacks every future reader. ## The Django-native fix The requirement was line breaks, and the DTL has filters for that: | Filter | Output | Escapes the input? | |---|---|---| | `linebreaks` | blank line becomes `</p><p>`, single newline becomes `<br>` | yes, unless the value is already safe or autoescaping is off | | `linebreaksbr` | every newline becomes `<br>` | same rule | | `safe` | nothing changes | **no — escaping is disabled** | ```django <div class="review-body">{{ review.body|linebreaks }}</div> ``` `linebreaks` escapes the review text and then inserts its own `<p>`/`<br>` tags, returning a safe string so the tags it added are not escaped again. The reviewer's `<img>` shows as text. Two details matter when you rely on it: 1. It skips escaping when the input is **already a safe string** — so `{{ review.body|safe|linebreaks }}` is still vulnerable. 2. It follows the **current autoescape setting**, so inside `{% autoescape off %}` it escapes nothing. ## When reviews really need rich text If the product decision is that reviews may contain bold, lists or links, escaping is the wrong tool — it would show the tags. The value must be passed through an **allowlist HTML sanitizer** (a library that keeps only permitted tags and attributes and drops everything else, including event handlers and `javascript:` URLs). Then: - sanitize on write (store clean HTML) or on render, but always before marking; - mark only the sanitizer's return value safe, in one well-named helper; - never mark the raw body safe anywhere else. Django does not ship such a sanitizer; `striptags` is not one, and Django's documentation warns that its output is not guaranteed to be HTML-safe. ## Fixes that do not work - **`{{ review.body|safe|escape }}`** — the `escape` filter uses `conditional_escape`, which leaves safe strings alone; Django's docs show this prints the value unescaped. - **`{{ review.body|force_escape|safe }}`** — this is safe but shows literal tags and no line breaks, which is the original problem. - **`{% autoescape off %}` around the block** — the same hole as `|safe`, applied to every variable inside the block and carried into included templates. ## How to find the rest A review-page bug rarely lives alone. In an audit, search for every escape hatch and justify each: - `|safe` and `|safeseq` in templates, - `{% autoescape off %}` blocks, - `mark_safe(` and `SafeString(` in Python, especially around f-strings or `%` formatting, - custom filters registered as safe that return unescaped input. As defence in depth, a Content Security Policy that forbids inline script limits what a missed payload can do — Django 6.0 added built-in CSP support — but it does not replace escaping.