Keep generated output out of executable contexts

Model output may be influenced by untrusted inputs, so it enters downstream systems with no special trust. The same string can be harmless when displayed as text and dangerous when interpreted as HTML, shell syntax, a database query or a filesystem path. The OWASP Top 10 for LLM Applications 2026 lists this as Improper Output Handling (LLM10:2026), and the Agentic Top 10 tracks the worst case, generated code that runs, as Unexpected Code Execution (ASI05:2026). Valid JSON does not make the values inside it safe or authorized.

Map every output destination: visible responses, generated reports, downloaded files, image and link rendering, email templates, database operations and agent tools. Safety checks must match each destination’s interpretation rather than applying one generic sanitizer to all output.

Consider the generated value <img src="https://outside.example.test/pixel?case=7">. In a text node it displays as characters. Assigned to innerHTML it creates an image element, and the browser fetches the URL even though no JavaScript runs. The security property for a text-only chat is therefore not “no script executed”; it is “no generated elements and no automatic external requests”. Inspect the DOM and network behavior of the final renderer.

Rich text is a separate feature contract. The code below renders plain answers with textContent. For formatted answers it parses Markdown with markdown-it’s html option off, so raw HTML stays visible text, then passes the result through DOMPurify with an allowlist that has no img element and accepts only https links. Exports and previews often use a different library, so test them separately: a safe chat renderer does not protect an HTML download.

For a database, use an application-owned statement and bound values. Binding a value in WHERE title = ? prevents that value from becoming SQL syntax. It does not make a model-authored statement safe: a perfectly parameterized DELETE FROM invoices WHERE tenant_id = ? may still be an unauthorized operation. Expose a narrow search function with current resource authorization rather than a generic SQL tool.

For process execution, avoiding a shell removes metacharacter interpretation but does not validate the invoked program’s arguments. A filename beginning with a dash can be read as an option unless the argument contract prevents it. Prefer a narrow operation with a fixed executable and explicit argument handling. Authorization and resource bounds still apply after syntax is constrained.

import DOMPurify from 'dompurify';
import MarkdownIt from 'markdown-it';

// Plain answers: the browser inserts characters, never markup.
export function renderPlain(element, modelText) {
  element.textContent = modelText;
}

// Formatted answers: Markdown with raw HTML disabled, then an allowlist sanitizer.
const markdown = new MarkdownIt({html: false, linkify: false});

export function renderRich(element, modelText) {
  element.innerHTML = DOMPurify.sanitize(markdown.render(modelText), {
    ALLOWED_TAGS: [
      'p',
      'em',
      'strong',
      'code',
      'pre',
      'ul',
      'ol',
      'li',
      'blockquote',
      'a',
    ],
    ALLOWED_ATTR: ['href'],
    ALLOWED_URI_REGEXP: /^https:\/\//i, // no javascript:, data: or plain http: links
  });
}

Use the framework’s normal text rendering for plain output: textContent in the DOM, {text} in React and {{ text }} in Vue all insert characters, not markup. Avoid dangerouslySetInnerHTML, v-html and innerHTML for model text. If a feature needs rich content, render Markdown with raw HTML disabled and sanitize the result with a maintained allowlist sanitizer such as DOMPurify, configured as in /domains/appsec/browser-security/rich-text-dom-security/. Remote images and automatic link previews create network requests that can carry data out, so allow them only when the product needs them.

Keep a Content Security Policy as defense in depth, not as permission to inject generated markup: script-src 'self' without 'unsafe-inline' stops injected script, and img-src 'self' stops pixel requests to other hosts. A policy does not stop deceptive links or every unwanted request, so test the final rendered document and browser requests, including exports and preview components that use a different renderer.

For database access, expose known operations with bound values and resource authorization rather than executing generated SQL. For process execution, use a narrow API with a fixed executable and an argument list, never a shell string. For structured output, validate the response against a schema (JSON Schema, Pydantic or Zod) to reject extra fields, wrong types and excessive sizes, then authorize the requested action separately: a valid object can still ask for something the user may not do. /domains/ai-emerging/llm-security/calling-llm-apis-safely/ shows the schema check on a real provider call in Python and TypeScript.

For generated paths or URLs, constrain the resource namespace and destination through the application’s normal file and network defenses. Avoid a recovery path that asks the model to “fix” a rejected action and then executes it without the same checks.

When running generated code is the feature itself, as in a data-analysis tool or a coding agent, run it in a disposable sandbox with no network, no secrets, no host mounts and hard limits, and keep its side effects behind an approval: /domains/ai-emerging/agent-security/agent-code-sandboxing/ covers the isolation options, the container flags and the escape tests.

Test the output boundary with controlled strings instead of hoping a live model emits a particular attack. Include ordinary punctuation, code examples and non-ASCII text so the repair preserves useful content. Verify DOM behavior, network activity and database or filesystem side effects, not just the transformed string, and record the renderer and library versions with the evidence. The output-rendering lab (/labs/output-rendering/) repairs a renderer that inserts model text as markup.

Removing a small list of substrings is fragile because equivalent syntax and different output contexts behave differently. Use the destination’s normal safe construction APIs and a reviewed rich-content policy where necessary. Escaping for HTML text is not escaping for an inline script, URL or shell; /domains/appsec/secure-coding/xss-output-encoding/ covers each context.

A content security policy can reduce the impact of some rendering mistakes, but it does not define which links are truthful or which data may be sent. Test the feature’s intended behavior directly; do not treat the absence of one CSP report as proof that no unwanted effect occurred.

Each row is a supplied output or operation and the result its destination must produce. The output-rendering lab on this page has you repair a renderer until the same cases pass.

Repair the code

XSS lab: Render a model’s answer as text instead of active markup

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP Top 10 for LLM Applications 2026 (LLM10 Improper Output Handling). 3 August 2026.
2. OWASP LLM05:2025 Improper Output Handling (2025 list; LLM10 in 2026)
3. OWASP Cross Site Scripting Prevention Cheat Sheet
4. DOMPurify README: Can I configure DOMPurify?
5. markdown-it API: MarkdownItOptions (html defaults to false). v15.0.2.
6. OWASP AI Agent Security Cheat Sheet

Reference information

Tags

Cross-site scripting (XSS)LLM application security

SDLC phase

DesignDevelopment

Role

DevelopersAppSec engineersPlatform engineers and SREs

ASVS 5.0.0 requirements

v5.0.0-1.2.4 · v5.0.0-1.2.5 · v5.0.0-1.3.1 · v5.0.0-3.2.2

Download this guide as Markdown

Continue exploring