# XSS (Cross-Site Scripting)

URL: https://softwaredictionary.org/terms/xss
Category: Security
Last updated: 2026-09-29

In short: XSS is a vulnerability that lets an attacker inject malicious JavaScript into a trusted website so that it runs in other users' browsers.

## What is XSS?

Cross-site scripting happens when a web application includes untrusted data, such as a comment, a search term, or a URL parameter, in a page without making it safe first. The browser cannot tell the attacker's script from the site's own code, so it runs it with the same permissions as the real site.

Once the script runs, it can read data on the page, act as the logged-in user, change what the user sees, or send information to the attacker. XSS comes in three main forms: stored XSS, where the payload is saved in a database and shown to every visitor; reflected XSS, where it is bounced back from a request such as a search URL; and DOM-based XSS, where front-end JavaScript inserts untrusted data into the page.

The main defense is output encoding: converting special characters like `<` and `>` into harmless text before inserting data into HTML, which frameworks such as React, Vue, and Angular do by default. Avoid raw HTML sinks like `innerHTML` or `dangerouslySetInnerHTML` with user data, clean any HTML you must allow with a well-tested sanitizer library, and add a Content Security Policy (CSP) header that restricts which scripts can run. Marking session cookies `HttpOnly` limits the damage by keeping them out of reach of scripts.

XSS is often confused with CSRF. In XSS the attacker's code runs inside the trusted site, while in CSRF the attacker's own site tricks the browser into sending a request to the trusted site; an XSS flaw can also defeat most CSRF defenses.

## Key takeaways

- XSS lets attacker-supplied scripts run in other users' browsers.
- It is caused by inserting untrusted data into pages without encoding.
- The three main types are stored, reflected, and DOM-based XSS.
- Defend with output encoding, safe DOM APIs, sanitization, and CSP.
- `HttpOnly` cookies reduce the impact of a successful attack.

## Example: Vulnerable vs. safe way to display user input

```javascript
const comment = getCommentFromUser(); // e.g. <img src=x onerror=alert(1)>

// Vulnerable: the browser parses the text as HTML and runs the script
commentBox.innerHTML = comment;

// Safe: the input is treated as plain text, never as HTML
commentBox.textContent = comment;
```

## Frequently asked questions

**What is the difference between XSS and CSRF?**

XSS injects malicious script into a trusted website so it runs in victims' browsers. CSRF tricks a victim's browser into sending an unwanted request to a site where they are logged in, without running any code on that site.

**Does React prevent XSS?**

React escapes values inserted with JSX by default, which blocks the most common XSS cases. You can still create vulnerabilities with `dangerouslySetInnerHTML`, unsafe `href` values such as `javascript:` URLs, or untrusted third-party code.

**What is a Content Security Policy?**

A Content Security Policy is an HTTP response header that tells the browser which sources of scripts, styles, and other resources are allowed. A strict policy can stop injected scripts from running even if an XSS bug exists.

## Sources

- [OWASP: Cross Site Scripting (XSS)](https://community.owasp.org/attacks/xss/)
- [OWASP Cheat Sheet: Cross Site Scripting Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt