XSS Playground

A simple fake social feed that shows reflected, stored, and DOM-based XSS in a safe browser-only demo. It also shows the small code change that stops each one.

JavaScript XSS OWASP Top 10 Web Security CSP

Reflected XSS

Reflected XSS happens when untrusted input is returned to the page and executed immediately after the application reflects it back to the browser.

Stored XSS

Stored XSS happens when malicious input is saved by the application, such as in a post or comment, and then runs whenever users load that content later.

DOM XSS

DOM-based XSS happens in client-side JavaScript when the page reads unsafe data and writes it into the DOM in a way that allows code to run.

01 - Reflected XSS High

Type a normal search term below, or click one of the sample payloads to try it as XSS. If the page treated it like HTML instead of text, a payload could run as soon as the page renders it back.

Search input

Rendered output

Nothing yet.

Vulnerable

// treats input like HTML
div.innerHTML = userInput;

Fixed

// treats input like text
div.textContent = userInput;

The root problem is simple. If the page treats attacker input like HTML, the browser may execute it.

02 - Stored XSS High

Write a normal post below, or click one of the sample payloads to try it as XSS. If a bad payload were saved and shown back to everyone, every visitor could be affected.

Username

Post content

Fake feed

Vulnerable

// saves raw HTML and renders it
post.innerHTML = savedPost;

Fixed

// escapes on output
post.textContent = savedPost;

Stored XSS is worse because the payload can keep hitting every new visitor until it is removed.

03 - DOM XSS Medium

Type a normal value below, or click one of the sample payloads to try it as XSS. This example copies a value from the fake URL hash into the page, so no server is needed for the problem to happen.

Fake URL hash

DOM output

Output appears here.

Vulnerable

// reads from the URL and writes HTML
div.innerHTML = location.hash.slice(1);

Fixed

// writes plain text only
div.textContent = location.hash.slice(1);

DOM XSS can be missed if you only look at server code. The browser JavaScript also needs to handle data safely.

04 - How to prevent XSS

Use textContent

If you only need to show text, use textContent instead of innerHTML.

Use CSP

A content security policy can help block injected scripts if something slips through.

Sanitize carefully

If HTML really must be allowed, use a trusted sanitizer instead of trying to write your own.

The core fix is always the same: treat untrusted input like data, not code.

This demo is a safe simulation. It does not run real attacker scripts or touch real cookies. The popup is there to show what would happen on a weak page.

How It Was Made

This project was built as a browser-only demo with plain HTML, CSS, and JavaScript. The goal was to make XSS easier to see without needing a backend or a real vulnerable site.

Click a topic to view the code

HTML and CSS build the layout, fake feed, payload chips, and cards. Vanilla JavaScript updates the demo sections, fills payloads, and shows the alert box. Fake feed data stands in for stored posts so the page stays safe to share publicly. Defense examples show the difference between unsafe HTML rendering and safer text output.

Q&A

Because textContent shows the text as text. It does not parse tags or attributes as real HTML.

Back to all projects