What is XSS in simple terms?

XSS is when an attacker gets their JavaScript code to run on your website, inside your users' browsers. This happens when your site displays user input without properly escaping it.

What can an attacker do with XSS?

Steal session cookies, redirect users to phishing sites, modify page content, capture keystrokes, or make requests on behalf of the user.

Does React prevent XSS?

React escapes values in JSX by default, which prevents most XSS. But using dangerouslySetInnerHTML, href attributes with javascript: URLs, or server-side rendering with unescaped data can still introduce XSS.

What is Cross-Site Scripting (XSS)?

The short version

Cross-Site Scripting (XSS) is when an attacker manages to run their own JavaScript on your website, inside your users' browsers. The script runs with full access to the page: it can read cookies, submit forms, redirect users, and steal data.

It's one of the most common web vulnerabilities. CWE-79 has tracked it for decades, and it consistently appears in the OWASP Top 10.

How does it happen?

The core problem is always the same: your application takes user input and puts it into the page without proper escaping. If I can type <script>alert('hacked')</script> into a form and your site renders it as HTML, my script runs in every browser that views that page.

The three types

Reflected XSS

The malicious script is part of the URL. The server reads it from the request and reflects it back in the response. Example: a search page that displays "You searched for: [whatever was in the URL]" without escaping.

An attacker crafts a URL with a script in it and tricks someone into clicking it.

Stored XSS

The script gets saved to your database and rendered to every user who views that content. Think comment sections, profile bios, or product reviews. This is more dangerous because the attacker doesn't need to trick individual users into clicking a link.

DOM-based XSS

The vulnerability is entirely client-side. Your JavaScript reads from a source the attacker controls (like window.location.hash or document.referrer) and writes it to the page using innerHTML or similar methods. The server never sees the malicious input.

The OWASP XSS guide covers all three types in detail.

Real-world impact

When an attacker's script runs in your user's browser, it can:

Steal session cookies and send them to the attacker's server (unless cookies are marked HttpOnly)
Capture everything the user types, including passwords and credit card numbers
Modify the page to show fake login forms
Make API requests as the authenticated user

How to prevent XSS

Escape output. Every time you render user-controlled data in HTML, escape it. Modern frameworks like React, Vue, and Angular do this automatically in most cases. The danger is when you bypass that protection with things like dangerouslySetInnerHTML or v-html.

Validate and sanitize input. Don't accept HTML where you don't need it. If a username field should only contain alphanumeric characters, enforce that.

Use Content Security Policy. CSP acts as a safety net. Even if XSS slips through your code, CSP can prevent the injected script from executing by blocking inline scripts.

Set HttpOnly on session cookies. This prevents JavaScript from reading them, which limits the damage even if XSS occurs. See the MDN cookie documentation.

Avoid dangerous APIs. In vanilla JavaScript, avoid innerHTML, document.write, and eval. Use textContent instead of innerHTML when inserting user text.

The framework trap

React, Vue, and similar frameworks escape by default. That's great. But developers bypass it constantly:

dangerouslySetInnerHTML in React
v-html in Vue
[innerHTML] binding in Angular
Template literals injected into the DOM

If you use these with user input, you have XSS. The framework won't save you.

Check your site

Want to know if your site has this issue? Scan it now and find out in 60 seconds.