Cross-site request forgery (CSRF) vs Cross-site scripting (XSS)

Why they differ

XSS runs the attacker's script inside the trusted site; CSRF runs nothing there and only borrows the user's login to send one request from outside.

Cross-site request forgery (CSRF)

Application security

An attack where a harmful page makes a user's browser send a request to a site they are logged in to, which acts as if they asked.

Formal

A flaw in a web application that carries out a state-changing request just because it arrives with the user's cookie; since the web browser attaches that cookie by itself, a page on another site can trigger the request without the user knowing.

In plain English

Like someone slipping a signed order form into your post - the shop sees your signature and fills the order, never asking whether you meant to send it.

In practice

A case officer in a municipality is logged in to the case system and opens a link in a mail; the page quietly submits a hidden form that changes the payout account on a citizen's case, and the system accepts it because the login cookie came along.

Why it matters

The attacker never needs the password or even sees the response; a single visit to the wrong page can change an email address or password, or move money, in the user's name.

Cross-site scripting (XSS)

Application security

An attack that smuggles a harmful script into a web page, so it runs in the browser of everyone who visits the page.

Formal

A flaw in a web application that places untrusted input into its pages without making it safe first; the web browser then runs that input as code with the same rights as the site's own code, so it can read what the user sees and act in their name.

In plain English

Like a notice board where someone pins up a note that, when read aloud, makes the reader hand over their house keys - the board itself never checks what is pinned to it.

In practice

An attacker posts a comment with a hidden script on a municipality's public consultation page; every resident who opens the page while logged in unknowingly hands the attacker their session.

Why it matters

The harmful code runs inside a site the visitor trusts, so the browser gives it the visitor's session and data; it remains one of the most often reported flaws in web applications.

Shared connections

Web application