# XSS vs CSRF

URL: https://softwaredictionary.org/compare/xss-vs-csrf
Last updated: 2026-09-30

In short: XSS injects malicious scripts that run inside a trusted website, while CSRF tricks a logged-in user's browser into sending unwanted requests to that site.

## What is the difference between XSS and CSRF?

Cross-site scripting (XSS) happens when an application includes untrusted input in a page without escaping it, so an attacker's JavaScript runs in other users' browsers with the site's full privileges. Cross-site request forgery (CSRF) happens when a malicious page makes the victim's browser send a request to a site where they are logged in, and the browser attaches their cookies automatically.

The difference is what the attacker controls. With XSS, the attacker's code runs on your origin, so it can read the page, steal data and act as the user in any way. With CSRF, the attacker cannot read anything; they can only fire a request blindly and hope it changes something, such as an email address or a money transfer.

The defenses differ too. XSS is prevented by escaping output, sanitizing any HTML you allow, avoiding unsafe APIs like `innerHTML`, and adding a Content Security Policy. CSRF is prevented with anti-CSRF tokens, `SameSite` cookies and checking the `Origin` header on requests that change data. XSS also defeats CSRF protection, because a script running on your own site can read the token.

A common misconception is that modern frameworks and browsers make both attacks obsolete. Frameworks escape output by default and some browsers now treat cookies as `SameSite=Lax` unless told otherwise, but raw HTML rendering, misconfigured cookies and `GET` requests that change data still leave real apps vulnerable.

| Aspect | XSS | CSRF |
| --- | --- | --- |
| Trust abused | The user's trust in the website | The website's trust in the user's browser |
| Where attack code runs | On the target site, in the victim's browser | On the attacker's own site |
| Can read data | Yes: page content, tokens, anything the script can reach | No: requests are sent blind and responses stay hidden |
| Root cause | Untrusted input rendered without escaping | Requests authenticated only by automatically sent cookies |
| Main defenses | Output escaping, HTML sanitizing, Content Security Policy | CSRF tokens, SameSite cookies, Origin header checks |
| Typical impact | Session theft, account takeover, defaced pages | Unwanted transfers, email or password changes |

## Choose XSS when

- Your pages display user-generated content such as comments or profiles.
- Code inserts HTML with innerHTML or renders raw markup.
- URL parameters or search terms are echoed back into the page.

## Choose CSRF when

- Your app relies on cookies to authenticate requests.
- Forms or endpoints change data without a CSRF token or Origin check.
- GET requests perform actions like deleting records or moving money.

## Frequently asked questions

**Does CSRF protection stop XSS?**

No. CSRF tokens do nothing against XSS, and an XSS flaw can even read CSRF tokens and bypass that protection. Each attack needs its own defenses.

**Do SameSite cookies prevent CSRF?**

`SameSite=Lax` or `Strict` blocks most CSRF attacks by not sending cookies on cross-site requests. It works best combined with CSRF tokens or `Origin` checks, which also cover older browsers and attacks from sibling subdomains.

**Which is more dangerous, XSS or CSRF?**

XSS is usually more severe, because the attacker's script can read data and do anything the user can. CSRF is limited to blind requests, but it can still cause serious damage like changing account details.

---

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