XSS: The Browser is the Database
Cross-Site Scripting turns the browser into an execution host. One unescaped string and the attacker runs JavaScript in your user session.
Beginner12 min
XSSOWASPWeb
Loading lesson…
Cross-Site Scripting turns the browser into an execution host. One unescaped string and the attacker runs JavaScript in your user session.
Cross-Site Scripting has been a fixture of the OWASP Top 10 since its inception. Classified as A03:2021 Injection alongside SQLi, XSS exploits the browser's trust in the response it receives from the server. When a web application reflects user input without escaping it, the browser cannot distinguish between code the developer wrote and code the attacker injected.
XSS inverts the SQL injection model. Instead of injecting code into the database, you inject code into the browser — but the mechanism is the same: user input is treated as code instead of data. A search results page that echoes the query string is the canonical example. When the server renders <p>You searched for: $query</p>, any HTML the attacker places inside $query becomes part of the DOM.
The standard proof-of-concept payload <script>alert(1)</script> shows a dialog box in the browser. If the server reflects the query unescaped, the browser parses the injected script tag and executes it. The `alert()` is a stand-in for anything an attacker might want to run — reading cookies, exfiltrating tokens, or rewriting the page.
Not all payloads need a <script> tag. Event handlers in HTML attributes also execute JavaScript: <img src=x onerror="alert(1)"> fires when the browser fails to load the image, and <a href="javascript:alert(1)">click</a> runs code on click. The browser provides dozens of script execution surfaces — the attacker only needs one to slip through.
Type a product name into the search field below, then try a payload like <script>alert(1)</script>. The search page reflects your query literally — and unsafely — back into the page. Toggle safe mode to see how HTML escaping neutralises the attack.
<!-- VULNERABLE - raw reflection -->
<p>You searched for:
<script>alert(1)</script>
</p>In October 2005, a 19-year-old security researcher named Samy Kamkar found a stored XSS vulnerability on MySpace. MySpace had filtered out<script>,<body>, andonclick but missedonmouseover combined withbackground: url('javascript:…')in CSS. Samy crafted a profile page that, when viewed, added the viewer as a friend and copied the payload to the viewer's own profile. The worm propagated exponentially, reaching over one million MySpace users within 20 hours — the first major XSS worm in history. MySpace had to shut down temporarily and Samy was sentenced to three years probabrtsdc resulting in the first felony conviction for a social-networking worm.
The Samy worm is the canonical case study because it demonstrates how XSS can self-propagate without any server-side exploit. The attack surface was a single unescaped field in the user profile, and the impact was a platform-wide outage. More recently, the British Airways 2018 data breach involving 380,000 payment records began with an XSS vulnerability in a third-party JavaScript library.
The primary defence is context-aware escaping — the application must encode values differently depending on whether they appear in an HTML element body, an attribute, a JavaScript string, or a URL. Server-side template engines like React's JSX escape HTML by default, butdangerouslySetInnerHTMLand similar APIs opt out of that protection and must be audited carefully.
// VULNERABLE - unescaped HTML reflection
res.send('<p>You searched for: ' + query + '</p>');
// SAFE - context-aware escaping
res.send('<p>You searched for: ' + escapeHtml(query) + '</p>');
// SAFE - Content Security Policy header
res.setHeader('Content-Security-Policy',
"default-src 'self'; script-src 'self'");
// A strict CSP blocks inline scripts and eval() even
// if an injection point exists in the HTML.A Content Security Policy (CSP) acts as a safety net. Even if escaping fails, a strict CSP prevents the browser from executing inline scripts or making requests to unknown origins. The combination of server-side escaping and a strict CSP is the industry standard for XSS defence. Input validation (e.g. rejecting HTML in search queries) is a useful additional layer but must never be the sole defence, since attackers find encoding bypasses.
<script>alert(1)</script> is the proof of concept, but event handlers like onerror and onmouseover are equally dangerous.1.What is the root cause of reflected XSS?
2.Which of the following is NOT a valid XSS payload?
3.How did the Samy worm on MySpace propagate to over one million users?