XSS Examples: Real Payloads and How They Execute

A clear XSS example is any case where attacker-controlled input reaches a browser-parsed output without proper encoding, so a string that looks like markup or script gets executed instead of displayed. The payload changes with the context it lands in, and understanding that mapping (input source to output sink) is the whole skill. Below are concrete, context-by-context examples you can reason about and test against your own code.

We are showing these to help you recognize and fix vulnerable patterns. Only run payloads against systems you own or are authorized to test.

What does a basic XSS attack example look like?

The canonical XSS attack example is a search field that echoes its query into the page. If the template inserts the raw parameter into HTML body content, this input executes:

<script>alert(document.domain)</script>

alert(document.domain) is a harmless proof marker: if a box pops with the site's origin, script is running in that origin. Attackers swap the body for something that reads cookies or forges requests. The bug is not the alert; it is that the browser parsed attacker text as a live script tag.

Modern browsers block <script> inserted via innerHTML after page load, so real-world payloads more often rely on event handlers, which run regardless.

Which XSS examples work in an HTML attribute context?

When your input lands inside an attribute rather than body text, you do not need a script tag. You need to break out of the attribute or supply an event handler. A classic image-based payload:

<img src=x onerror=alert(1)>

The src is invalid, so the browser fires onerror, running the JavaScript. Anchor tags are just as exploitable when input reaches an href:

<a href="javascript:alert(1)">click</a>

If the app inserts your value inside an existing attribute, breaking out is the move. Input like " onmouseover="alert(1) closes the current attribute and injects a new event handler. These attribute-context cases are exactly why generic HTML-body escaping is not sufficient: the encoding rules differ per context, and a value safe in one place is dangerous in another.

What is a JavaScript-context XSS example?

The riskiest sink is input written directly into a script block or passed to a function that evaluates strings. If a page builds JavaScript like assigning a variable from a server-rendered value, a payload that closes the string and adds a statement runs immediately:

var q = "shoes"; alert(1); //";

Anything routed into eval, setTimeout with a string argument, Function(), or element.innerHTML is a candidate. Client-side sinks like innerHTML, outerHTML, document.write, and insertAdjacentHTML are where DOM-based cases live, and they never touch the server, which is why response-only scanners miss them.

Where can you find curated XSS payloads on GitHub?

If you are building a test corpus, well-known open collections of xss payloads github repositories catalog thousands of variants by context, browser quirk, and filter bypass. The two most cited are PayloadsAllTheThings and the SecLists project. They are useful for two honest reasons: writing regression tests so a fixed injection point stays fixed, and understanding evasion so your sanitizer allowlist is not naive.

A word of caution: dumping a list of payloads into a fuzzer without understanding context produces noise. The payload that fires in an attribute will sit inert in a properly encoded body, and vice versa. Match the payload to the sink.

How should you test for XSS safely?

Reliable XSS testing is more than pasting alert(1) into every field.

• Trace the data flow. Identify where each input renders: body, attribute, script, URL, or a DOM sink. The context dictates the payload.
• Use a unique marker. Inject a distinctive token first, then view source to see whether it landed in a dangerous context before you try to execute anything.
• Test stored paths, not just reflected. Submit through the form, then load the page that displays the saved value, including admin views that render user content.
• Cover DOM sinks. Search your client code for innerHTML, document.write, location, and eval, then check whether attacker-controlled data reaches them.

Doing this by hand across a large app does not scale. Static analysis follows tainted input from source to sink in your code, and dynamic scanning drives the running app with real requests. Safeguard's SAST and DAST run both and correlate the results, so a reflected finding and the exact vulnerable line show up together. Teams choosing between tools often start with our comparison of Safeguard and Snyk for how coverage differs across these injection classes.

How do you fix the XSS examples above?

Each example above closes the same way: encode for the destination context and stop inserting raw input into markup.

• HTML body input: HTML-entity encode, or let your framework auto-escape.
• Attribute input: attribute-encode and quote every attribute; reject javascript: URLs with an allowlist of schemes.
• Script context: never build JavaScript from user input; pass data through JSON.parse of a safely encoded payload or via data- attributes read with textContent.
• DOM sinks: prefer textContent over innerHTML; when HTML is required, sanitize with DOMPurify.

FAQ

What is the simplest XSS example to demonstrate the bug?

Injecting <script>alert(1)</script> into a field that reflects unencoded input into the HTML body. If the alert fires, the page executed attacker-supplied script. It is a proof of concept, not the actual attack, which would exfiltrate a session or forge a request.

Why do so many XSS examples use onerror or img tags?

Because browsers block script tags injected via innerHTML after load, but event handlers like onerror still fire. An <img src=x onerror=...> payload is reliable across many injection points where a raw script tag would be ignored.

Are xss payloads github lists safe to use?

The lists themselves are just text. The risk is where you run them: only against systems you own or are authorized to test. Used for regression tests and understanding evasion, curated payload sets are a legitimate part of an AppSec workflow.

Does encoding once fix every XSS example?

No. Encoding must match the context. A value HTML-encoded for the body is still dangerous inside an attribute or a script block. Correct output handling is per-context, which is the single most common mistake behind live XSS bugs.