XSS vs CSRF: What Is the Difference?

CSRF and XSS are the two classic ways to make a victim's browser do something they did not intend, and they are constantly confused. They are genuinely different bugs with different requirements and very different power. Knowing which one you are looking at tells you what to try and what the impact ceiling is. Practice both on a free live target.

The one-line difference

• XSS runs your script inside the application's origin. The browser executes attacker-controlled JavaScript as if the site wrote it.
• CSRF forges a request from outside the application. No script runs in the origin, the attacker's page simply causes a request that the browser sends with the victim's cookies.

XSS is code execution in the page. CSRF is a request the page never meant to send. That distinction drives everything else.

What each one needs

They have almost opposite requirements:

• XSS needs an injection sink: a place where attacker input reaches the page as executable script or markup without proper escaping. It does not need the victim to be logged in, and it does not care about CSRF tokens.
• CSRF needs ambient cookie auth and predictable parameters: the victim must be logged in with a cookie the browser auto-attaches, and the attacker must be able to build the whole request in advance. It does not need any injection point in the app.

So an app can be vulnerable to one and not the other. A static marketing page with a reflected parameter can have XSS but nothing to CSRF. A tightly-escaped banking app can be free of XSS yet have a CSRF hole on a settings form.

Why XSS is strictly more powerful

Here is the part that matters most in practice. XSS can do everything CSRF can do, and then everything CSRF cannot:

• CSRF fires a blind, pre-built request and never sees the response. XSS runs in the origin, so it can read the response, scrape data, and chain multi-step actions.
• CSRF is stopped by an unpredictable token. XSS reads the token out of the DOM and submits a perfectly valid request, so the token is no obstacle at all.
• CSRF cannot touch HttpOnly cookies or custom-header auth. XSS does not need the cookie value, because it acts from within the session, making requests the browser authenticates automatically.

This is why a report of XSS outranks a report of CSRF on the same action: the XSS already contains the CSRF, plus the ability to defeat the defense that would have stopped the CSRF.

A side-by-side comparison

                     XSS                          CSRF
Where it runs        inside the app's origin      from an attacker's own page
Needs                an injection sink            ambient cookie auth + predictable params
Victim logged in?    not required                 required
Reads the response?  yes                          no (write-only)
Beaten by CSRF token no                           yes (if the token is enforced)
Beaten by SameSite   no                           largely yes
Relative power       strictly greater             a subset of what XSS can do

Where they overlap: CSRF via XSS

The overlap is the most dangerous case. When an app has a solid CSRF token, you cannot forge the request from outside, but if the same app also has XSS, your script reads that token from the page and submits the request from the inside. The CSRF defense is intact and completely bypassed at the same time. That technique has its own walkthrough in CSRF via XSS, and the exploitation details live in the XSS cluster. It is the reason "we use anti-CSRF tokens" is never an answer to an XSS finding.

Which to reach for

If you can inject script, pursue XSS: it is more powerful and subsumes CSRF. If you cannot, look for CSRF on the state-changing actions, where a weak or missing token check is a common and high-impact finding. In an assessment you test for both, because they defend against different things and an app can fail either independently.

Where to go next

Go hands-on with the most common CSRF finding in bypassing token validation, or see how the browser default of SameSite changes the game in bypassing SameSite restrictions. Or try both bug classes on a free live target.