AI-Generated XSS (Cross-Site Scripting) Review Rules

Purpose

Use these rules when an AI coding assistant writes or edits code that renders data of uncertain origin into a page. The goal is to stop a generated component, template, or DOM update from shipping a cross-site scripting hole because it renders correctly for the happy-path input and looks like ordinary UI code.

This is a review policy, not an XSS tutorial. It tells reviewers what must be true about a generated change's encoding, sinks, and sanitization before the change is safe to merge.

Review Inputs

Collect enough context to know where untrusted data flows and how it is rendered.

• Every place the change writes a variable into HTML, an HTML attribute, inline JavaScript, a URL, or CSS.
• Whether each variable originates from user input, a query parameter, a third-party API response, or stored content that was ever user-controlled.
• Which DOM APIs or template constructs the change uses to do the writing, and whether any of them bypass the framework's default auto-escaping.
• Whether the change introduces or modifies an HTML sanitizer, a Content-Security-Policy header, or a third-party script include.

Context-Correct Encoding Rules

• Match the encoding to the context, not the data type: HTML body, HTML attribute, JavaScript, URL, and CSS each parse differently, and the wrong encoding for a context can still allow execution.
• HTML body context (<div>UNTRUSTED</div>): use HTML entity encoding, or a safe sink such as .textContent.
• HTML attribute context (<div attr="UNTRUSTED">): quote the attribute with " or ', use HTML attribute encoding, and only place untrusted data into attributes that cannot execute (never onclick, onerror, href with a javascript: scheme, or similar event/URL attributes without extra validation).
• JavaScript context: the only safe placement for untrusted data is inside an already-quoted string literal, and it must use JavaScript-specific encoding there; never build a <script> block or event handler by concatenating untrusted strings into unquoted code.
• URL context: URL-encode the value first, then apply HTML attribute encoding when the URL is placed in href or src; validate the scheme against an allowlist before use.
• CSS context: restrict untrusted data to a CSS property value, never a selector or property name, and prefer element.style.property = value (a safe sink) over building a <style> block from strings.

Dangerous Sinks And Framework Escape Hatches

• Treat these as unsafe unless the value has first passed through a maintained HTML sanitizer immediately before the call: innerHTML, outerHTML, insertAdjacentHTML, document.write, document.writeln.
• Treat these framework escape hatches the same way: React's dangerouslySetInnerHTML, Vue's v-html, Angular's bypassSecurityTrustAs* family, and any unsafeHTML/raw-HTML helper.
• Prefer safe sinks that always treat their argument as text, never markup: .textContent, .setAttribute(name, value) with a hardcoded attribute name, .value, .className, document.createTextNode.
• Flag eval, new Function, setTimeout/setInterval called with a string argument, and any dynamic <script src> built from untrusted input.
• A modern framework's default template syntax already HTML-encodes interpolated values — the risk is almost always in code that deliberately opts out of that default, not in ordinary template bindings.

Sanitization And CSP Rules

• When a feature must render user-authored HTML (rich text, markdown preview, pasted content), sanitize with a maintained library (for example DOMPurify) and keep it patched, since sanitizer bypasses are discovered and fixed on an ongoing basis.
• Sanitize as the last step before rendering; if sanitized output is modified or concatenated with more untrusted data afterward, the sanitization is void.
• Use Content-Security-Policy as defense in depth, tuned for the specific application, not as a blanket policy assumed to cover every legacy page — it does not replace context-correct encoding or sanitization.
• Where the browser target supports it, consider Trusted Types (Content-Security-Policy: require-trusted-types-for 'script') to force DOM XSS sinks through a vetted policy instead of accepting plain strings.
• Do not rely on an input-side validator, HTTP interceptor, or WAF as the primary XSS defense: none of them have enough context to know which output context a given value will render into, and none of them stop DOM-based XSS that never touches the network.

Merge Blockers

Block merge when any of these is true.

• Untrusted data reaches innerHTML, dangerouslySetInnerHTML, v-html, document.write, or an equivalent sink without prior sanitization.
• A variable is placed inside a <script> block, an HTML comment, a <style> block, or an unquoted attribute — a dangerous context that output encoding cannot fully protect.
• A URL built from untrusted input is used in href, src, or a redirect without scheme validation, allowing a javascript: or data: URL.
• An HTML sanitizer is applied and then the result is mutated or concatenated with more untrusted data before render.
• The only stated defense is a Content-Security-Policy header, a WAF, or an input-side filter, with no context-correct output encoding or sanitization at the render point.

Review Checklist

• {"task": "Context-correct encoding", "description": "Every untrusted value uses the encoding for its actual context (HTML body, attribute, JS, URL, CSS)"}
• {"task": "No unsafe sinks", "description": "innerHTML/dangerouslySetInnerHTML/v-html/document.write are absent, or the value is sanitized immediately before use"}
• {"task": "Safe sinks preferred", "description": "textContent, setAttribute with a hardcoded name, and .value are used wherever markup rendering isn't required"}
• {"task": "URL scheme validated", "description": "URLs built from untrusted input are allowlisted to http/https before use in href/src/redirects"}
• {"task": "Sanitizer applied last", "description": "HTML sanitization happens immediately before render and isn't followed by further concatenation or mutation"}
• {"task": "CSP is secondary", "description": "Any CSP/WAF/interceptor is documented as defense in depth, not the sole XSS control"}

AI Review Rules

AI assistants can write and review rendering code, but they should show their evidence.

• Ask the assistant to list every place the change writes untrusted data into HTML, JavaScript, a URL, or CSS before judging safety.
• Require the assistant to name the specific sink or template construct used for each write, and state whether it is a safe sink, a dangerous sink, or a dangerous sink paired with sanitization.
• Have the assistant show where sanitization happens and confirm nothing runs after it that could reintroduce unsanitized data.
• Do not let the assistant claim a Content-Security-Policy header alone makes a dangerous sink safe.
• Re-run review after any change to rendering logic, sanitizer configuration, or third-party script includes.

Troubleshooting

• Encoded output shows literal </> instead of rendering markup: that is expected for HTML entity encoding of plain text; if markup rendering is actually required, sanitize the HTML instead of switching back to an unsafe sink.
• A sanitizer strips content the feature needs: adjust the sanitizer's allowlist of tags/attributes rather than bypassing sanitization or switching to innerHTML with raw input.
• It renders fine in the framework's template but breaks when built manually: the framework's default binding already encodes for you; a manual DOM write or raw HTML string bypasses that and needs its own encoding or sanitization.
• CSP reports block a legitimate inline script: move the script to an external file or a nonce-based include rather than relaxing CSP to unsafe-inline, and keep pursuing output-side fixes for the underlying sink.

Duplicate And History Check

Before adding new HTML-rendering or sanitization logic, confirm the codebase does not already have a shared rendering helper, template component, or sanitizer wrapper that solves this. A generated change that reaches for a raw DOM API or hand-rolled encoding next to an existing safe helper should be treated as suspicious — check whether the existing helper was simply not reused before introducing a second, parallel mechanism.

Context Reference

Sources

• OWASP Cross-Site Scripting Prevention Cheat Sheet
• OWASP DOM-based XSS Prevention Cheat Sheet
• OWASP XSS attack reference
• MDN Web Docs: Cross-site scripting (XSS)
• CWE-79: Improper Neutralization of Input During Web Page Generation

• Source repositorygithub.com 2026-07-16T13:01:56+00:00
• Documentationcheatsheetseries.owasp.org
• Submitted by lourincedaging0-commits2026-07-15