XSS
Cross-site scripting
Untrusted content is interpreted as script or markup in a victim’s browser. The correct defense depends on the output context: HTML text, an attribute, a URL or a script.
- Fix it in your stack
- Cross-site scripting (XSS) fix cards (9 stacks) · CWE-79 page
- Defined in
- MITRE CWE-79
- Identifiers
- CWE-79: Cross-site scripting (XSS)
Covered in
Prevent XSS at the output boundary
Choose text rendering, context-aware encoding, or deliberate HTML sanitization according to how the browser will interpret the value.
Prevent DOM XSS, postMessage abuse and client-side injection
Trace attacker-controlled values from the URL, messages and storage to the browser APIs that parse HTML or run code, then close those sinks with safe APIs, a sanitizer, Trusted Types and strict message checks.
Render rich text without granting it application privileges
Choose text rendering or a restricted HTML policy, then test the final DOM after every transformation.
Keep generated output out of executable contexts
Choose safe rendering and narrow operations so model text cannot become browser code, database syntax or an unrestricted command.
Apply CISA Secure by Design: principles, pledge goals and evidence
What CISA's Secure by Design guidance and pledge ask of software manufacturers as of October 2026, and how to turn each of the three principles, the seven pledge goals and the Product Security Bad Practices into engineering actions, metrics and evidence.
Configure CORS and CSP around the browser capabilities you need
Control who can read API responses and which resources a page may execute without confusing either control with authorization.
All 7 pages that cover XSS in the library
Practice: XSS lab: Render a model’s answer as text instead of active markup · CORS policy lab: Grant CORS to the right origins only · CSP builder lab: Build a strict Content-Security-Policy · HTML sanitization lab: Configure a sanitizer for user comments