What is cross-site scripting in one sentence?

Cross-site scripting is a vulnerability that lets an attacker run their own JavaScript inside another user's browser session on a trusted website.

What are the three types of XSS?

Stored XSS, where malicious script is saved on the server and served to every visitor; reflected XSS, where the script bounces off the server from a crafted link; and DOM-based XSS, which happens entirely in client-side code.

How do you prevent XSS?

Context-aware output encoding, a strict Content Security Policy, framework auto-escaping, and treating any HTML built from user input as dangerous unless run through a vetted sanitizer.

Does React prevent XSS automatically?

React escapes values rendered as text by default, but dangerouslySetInnerHTML, unsanitized href or src attributes, and injected script URLs can still introduce XSS.

Why is XSS dangerous if it just runs JavaScript?

That JavaScript runs with the victim's privileges on the trusted site, so it can steal session tokens, perform actions as the user, capture keystrokes, or rewrite the page to phish credentials.

Glossary · Security

What is Cross-Site Scripting (XSS)?

Cross-site scripting is a vulnerability that lets an attacker get their own JavaScript to run inside another person's browser while that person is on a trusted website. Because the malicious code executes with the full privileges of the site the victim is logged into, it can quietly steal their session, act on their behalf, or rewrite the page to harvest passwords — all without the attacker ever touching the victim's machine directly.

The core idea

A browser trusts the code a website sends it. XSS abuses that trust: if an attacker can sneak a snippet of script into the HTML a site serves, the victim's browser runs it as though it came from the site itself. The root cause is the same mix-code-with-data mistake behind SQL injection, except the interpreter being abused is the browser rather than the database. Any place a site reflects user input back into a page without properly encoding it is a candidate for XSS.

The three flavors

Stored XSS is the most dangerous: the attacker's script is saved on the server — in a comment, a profile bio, a support ticket — and served to everyone who views that content, including admins. Reflected XSS bounces off the server immediately, usually through a crafted link the attacker tricks a victim into clicking, so the payload is never stored. DOM-based XSS never reaches the server at all; it happens when client-side JavaScript reads from the URL or page and writes it back into the document unsafely. All three end the same way: attacker code running in a trusted context.

What an attacker gains

Once script runs in the victim's session it can read cookies and tokens not protected by HttpOnly, make authenticated requests as the user, log keystrokes, swap out a login form for a fake one, or chain into a worm that spreads through every profile that views the infected one. On internal admin tools the stakes are even higher, because a single XSS against an administrator can hand over the keys to the whole application. The damage is bounded only by what the victim's account is allowed to do on the site.

How to prevent it

The primary defense is context-aware output encoding: escape data differently depending on whether it lands in HTML, an attribute, JavaScript, or a URL. Modern frameworks like React, Angular, and Vue auto-escape text by default, which removes most reflected and stored XSS — until a developer reaches for an escape hatch such as dangerouslySetInnerHTML. Layer on a strict Content Security Policy to limit what scripts can run even if a payload slips through, set HttpOnly and SameSite on session cookies, and route any user-supplied HTML through a vetted sanitizer rather than rolling your own.

At QUANT LAB

XSS is one of the first things we probe in a web application penetration test, because it hides in the gaps frameworks do not cover — rich-text editors, markdown renderers, SVG uploads, and any feature that renders HTML from user data. On the build side, the apps we ship lean on framework auto-escaping, ship a tuned Content Security Policy, and sanitize untrusted HTML server-side. We treat XSS the way we treat the rest of the OWASP Top 10: as a category to design out, not patch in after a report lands.

Why CSP matters

A Content Security Policy is the seatbelt for XSS: even when a payload makes it onto the page, a well-written policy can stop the browser from executing inline scripts or loading code from attacker-controlled domains. It does not replace encoding — a site that relies on CSP alone is one misconfiguration away from trouble — but it dramatically shrinks the blast radius of a missed bug. Pairing strong encoding with a strict, nonce-based policy is the combination mature teams converge on, and it pairs naturally with the other browser-trust defenses behind CSRF protection.

Long-form deep-dives that use this term

All posts

Related terms

Want your app tested for XSS?

We hunt cross-site scripting in the corners frameworks miss and ship apps hardened against it. Book a 30-minute call.

Web app pentest