Security · Comparison
XSS vs CSRF vs SQL injection
Three classic web attacks aimed at different layers. XSS runs an attacker's script inside your pages, CSRF borrows a visitor's signed-in browser, and SQL injection slips commands into your database queries.
3 options · 7 questions side by side · updated
| Compare | XSS | CSRF | SQL injection |
|---|---|---|---|
| What is attacked | Other visitors' browsers | A signed-in user's session | The database behind the app |
| Root cause | User text shown as HTML or script | Cookies sent on requests from other sites | User input pasted into SQL text |
| Attacker gains | Acts as the victim inside the page | One unwanted action as the victim | Reads, changes or deletes data |
| Main defence | Escape output, sanitise HTML | SameSite cookies and CSRF tokens | Parameterised queries |
| Extra layers | Content Security Policy, HttpOnly cookies | Origin checks, no changes on GET | Least-privilege database user, a WAF |
| Framework help | React, Vue and Svelte escape by default | Django, Laravel and Rails check tokens | ORMs and query builders use parameters |
| Classic mistake | dangerouslySetInnerHTML with user input | Changing data on a GET request | Building SQL by joining strings |
How to choose between XSS, CSRF and SQL injection
- Treat XSS as an output problem: encode or sanitise everything shown to users, with a CSP as a safety net.
- Treat CSRF as a cookie problem: SameSite cookies plus tokens or Origin checks on every request that changes data.
- Treat SQL injection as a query problem: pass user input as parameters, never as part of the SQL text.
The options
- XSSAn attack where a site ends up including an attacker's code in its own pages, so the code runs in other visitors' browsers with their signed-in access.
- CSRFAn attack where another website quietly makes a signed-in visitor's browser send a request to your site, such as one that changes their email address, riding on the cookies the browser already holds.
- SQL injectionAn attack where text typed into a form or URL is treated as part of a database command, letting an attacker read, change or delete data they should never reach.
More comparisons
- Hashing vs encryption vs HMACThree building blocks that are easy to mix up. Hashing makes a fingerprint, encryption hides data until the right key reveals it, and HMAC proves a message came from someone who holds a shared secret.
- Bug bounty vs penetration testingBoth pay outside experts to find weaknesses before criminals do. A penetration test is a scheduled, scoped engagement that ends in a report; a bug bounty is a standing invitation that pays for each valid finding.
- Node.js vs Deno vs BunThree runtimes for JavaScript and TypeScript on the server. Much of the same code runs on all three; they differ in built-in tools, security defaults, speed and how long each has been used in production.
- Express vs Fastify vs HonoThree JavaScript web frameworks with a similar feel. Express is the long-standing default, Fastify focuses on throughput and structure, and Hono is built on web standards so it can run almost anywhere.
- FastAPI vs Django vs FlaskThree widely used Python web frameworks. Django includes almost everything, Flask includes almost nothing, and FastAPI focuses on typed, self-documenting APIs.
- REST vs GraphQL vs tRPC vs gRPCFour ways for apps and services to ask a backend for data. They differ in who can call them, how strictly the contract is typed, and what travels over the wire.
Crafted in the dark. Shipped to the world.
Tell us what you are building. You get a private project space with a proposal and a line-by-line quote within a day.