Both are client-side attacks, but XSS runs code in the browser while CSRF rides the user's session.
| XSS | CSRF | |
|---|---|---|
| Full name | Cross-Site Scripting | Cross-Site Request Forgery |
| Attack type | Inject and execute JavaScript | Forge authenticated HTTP requests |
| What the attacker gets | Full control of the page — steal tokens, keylog, redirect | One action performed as the victim |
| Requires victim interaction? | Victim visits the vulnerable page | Victim visits the attacker's page |
| Attacker sees response? | Yes — the script runs in the victim's browser | No — blind request |
| Same-origin policy | Bypassed (script runs in the target's origin) | Enforced (attacker can't read the response) |
| Key defense | Output encoding, CSP | CSRF tokens, SameSite cookies |
XSS is strictly more powerful than CSRF. If you have XSS, you can do everything CSRF can do and more — you can read the CSRF token from the page and submit any form you want. That's why XSS bypasses CSRF protections.
CSRF is the weaker cousin. You can trigger actions but you can't read responses. You can't steal data directly. You're limited to whatever the victim's session allows in a single request.
XSS can be used to perform CSRF attacks (read the token, submit the form). But CSRF can also be used to trigger stored XSS — if a CSRF lets you inject content into a field that's not properly encoded, you've chained CSRF into XSS.
XSS is the #1 most reported vulnerability on HackerOne. CSRF reports have dropped significantly since browsers started defaulting to SameSite=Lax cookies. But CSRF isn't dead — method override bypasses and cookie refresh techniques still work in specific scenarios.