Injection, XSS and CSRF all end with something acting on an attacker's behalf under someone else's authority. What actually distinguishes them?
Ask who is confused. In injection an interpreter mistakes data for code; in XSS the victim's browser mistakes attacker script for the site's own; in CSRF nothing is confused about the content at all — the server just can't tell who intended the request.
* One root cause, three faces — and each fix is the same move: split data back out of the instruction channel. *
| What goes wrong | Whose privileges are used | Attacker needs to… | Defused by | |
|---|---|---|---|---|
| Injection (SQL, OS, XPath) | an interpreter parses data as code | the application's (e.g. its DB account) | reach a string that is concatenated into a command | parametrized APIs; least privilege caps the damage |
| XSS | the browser attributes attacker script to your origin | the victim's, in their own session | get their bytes into a page your site serves | contextual output encoding; CSP as a backstop |
| CSRF | the server can't distinguish an intended request from a triggered one | the victim's, via their auto-attached cookie | only make the victim's browser send a request | a secret their page can't read (token), or SameSite |
Two distinctions people mix up most often:
- XSS vs CSRF. XSS lets the attacker run code in your origin — they can read the page, the DOM, the session token, and do anything the user could. CSRF lets them fire one request blind: they choose the action but never see the response. So XSS is strictly the more powerful of the two, and — importantly — XSS defeats CSRF tokens, because a script running on your origin can simply read the token off the page. Fixing CSRF while leaving XSS open protects nothing.
- Injection vs XSS. Both are "untrusted input became code", which is why they feel the same. The interpreter differs, and so does the fix's location: injection is stopped where the command is built (server-side, at the data layer), XSS where the page is rendered (at the output boundary, in whatever context applies).
The unifying idea: every one of them is a boundary where data and instructions share a channel. Keep them in separate channels — bound parameters, encoded output, an unguessable token — and all three classes close.