XSS Payload Cheat Sheet
This cheat sheet is built for defenders, reviewers, and developers. It summarizes how XSS payloads are usually categorized, what unsafe rendering patterns they target, and which mitigations stop them. It is intentionally defensive: enough to recognize and fix risk, without turning into a copy-paste exploit list.
Why XSS is still everywhere
Cross-site scripting stays common because it is not just one bug. It is a family of bugs caused by rendering untrusted data in the wrong context. Teams fix one reflected case, then reintroduce the risk through a markdown component, a search UI, a chat widget, or a dashboard using unsafe HTML insertion.
Payload categories by context
HTML context
If untrusted input lands directly inside markup, attackers look for tag-breaking input or event handler execution. The defense is HTML escaping plus avoiding unsafe insertion APIs.
Attribute context
Payloads often aim to break out of quoted attributes or reach URL-based sinks. Defense requires context-aware attribute encoding and strict validation for src, href, and style values.
JavaScript context
When data is interpolated into inline scripts, attackers target quotes, escaping behavior, and string termination. Defense is to avoid inline scripts and serialize data safely.
URL context
Client code that trusts navigational input can allow javascript: style payloads or dangerous redirects. Defense is protocol allow-listing and safe URL construction.
DOM sink context
Modern frontend apps often create risk through sinks like innerHTML, dangerouslySetInnerHTML, document.write, or unsanitized markdown renderers. Defense is sink elimination or sanitizer-backed rendering.
Bypass patterns to watch for
- Filters that block a few tags but do not account for alternate encodings or event handler vectors.
- Sanitization applied before decoding, templating, or markdown transformation changes the final output.
- Framework escapes are bypassed when teams drop into raw HTML helpers for convenience.
- Stored rich-text content that is safe in one view but unsafe in another component with different rendering rules.
Defenses that actually work
Output encoding must match the output context. That means HTML encoding for HTML, attribute encoding for attributes, safe serialization for JavaScript, and strict URL validation for navigational values. Then remove dangerous sinks wherever possible.
Pair those changes with a real Content Security Policy, secure templating defaults, and code review rules that flag unsafe APIs. If your stack uses React or Next.js, make every use of raw HTML rendering exceptional and reviewed.
For a broader list of related classes, bookmark the Top 50 vulnerabilities reference alongside this page.
Find XSS-prone surfaces faster
Scan forms, reflected parameters, and frontend rendering paths to see where XSS deserves a deeper review.
Check Your App