Cross-site scripting (XSS)
Also known as: XSS, cross site scripting, XSS attack
Cross-site scripting (XSS) is a web security flaw where an attacker gets a website to include malicious JavaScript in pages that other visitors load.
The script then runs in those visitors' browsers as if it came from the trusted site, letting the attacker steal session cookies, capture keystrokes, or change what the page shows. While modern frameworks and browser protections have reduced XSS, it remains one of the most frequently reported web vulnerabilities.
Cross-site scripting (XSS), explained at three levels
At home
Imagine a community notice board where anyone can pin a note, and a prankster pins one with hidden instructions that everyone who reads it automatically follows. Cross-site scripting works like that. An attacker hides code in something a website displays, such as a comment, and your browser runs it as if the trusted site sent it, letting the attacker grab your login or change the page.
At work
Cross-site scripting is a website flaw that lets an attacker plant malicious code in pages other visitors load, often through comments, search results, or links. The code runs in each visitor's browser as if it came from your trusted site, so it can steal logged-in sessions or show fake content. For a business, that means hijacked customer accounts and damaged trust.
At home
Web pages mix content and code. If a site takes what someone typed, such as a comment, and shows it to other visitors without cleaning it, an attacker can type code instead of text. Your browser then sees that code as part of the trusted website and runs it. Because it runs as that site, it can read the page, act on your behalf, or send your session cookie to the attacker, who can then use your logged-in account.
At work
Stored XSS saves the payload in the site, such as a forum post, so every viewer runs it. Reflected XSS bounces the payload off a link the victim clicks, and DOM-based XSS happens entirely in the page's own JavaScript when it writes untrusted data into the page. Prevention is context-aware output encoding, which turns special characters into harmless text, plus sanitizing any rich text. A Content Security Policy limits which scripts can run, catching mistakes encoding missed.
At home
XSS is tricky because everything looks legitimate. The address bar shows the real site, the padlock is there, and the page looks normal, so your usual caution does not help. The attack abuses the trust your browser places in that site. Browsers and frameworks now block many cases, but not all. In my view, logging out of sensitive sites when you are finished is a small, useful habit, because it limits what a stolen session can do.
At work
Modern frameworks such as React and Angular escape output by default, so most XSS now appears where developers bypass that, through raw HTML insertion APIs, unsafe URL handling such as javascript: links, or third-party widgets. Set HttpOnly cookies so scripts cannot read session tokens, use SameSite flags, and deploy a strict nonce-based CSP. Trusted Types in Chromium browsers can block dangerous DOM sinks entirely. Include XSS in automated scanning and code review, and audit third-party scripts, which run with full page privileges.
Real-world examples
At home
Carlos clicked a link to a forum post that looked normal. A hidden script in the post stole his session, and someone posted spam from his account until he logged out everywhere.
At work
Aisha is a web developer at a Toronto media company. A bug bounty researcher found an XSS flaw in the comments section, and she fixed it by properly encoding user content and adding a Content Security Policy.
How it compares
| feature | Cross-site scripting (XSS) | SQL injection |
|---|---|---|
| Where code runs | Visitor's browser | Website's database |
| Who's harmed directly | Site users | Site owner's data |
| Typical impact | Session theft, fake content | Data theft or deletion |
| Main fix | Output encoding and CSP | Parameterized queries |
XSS turns a website against its visitors.
For analysts
I'd make sure web projects use frameworks that escape output by default and set a Content Security Policy. Those two choices prevent most XSS without slowing developers down.
History & origin
Microsoft security engineers coined the term 'cross-site scripting' around 2000 as dynamic websites spread. In October 2005, the 'Samy worm' used an XSS flaw on MySpace to add more than a million friends to its creator's profile in about 20 hours, the fastest-spreading worm at the time, and led to a criminal conviction. XSS ranked high on the OWASP Top 10 web risks for years. Browsers added defences such as Content Security Policy (CSP), first shipped around 2010 and 2011, and frameworks like React escape output by default. XSS is still among the most common findings in bug bounty programs. In my view, XSS persists because the web mixes code and content so freely, and every shortcut reopens the door.