Side by side
SQL InjectionvsXSS
What is the difference between SQL injection and XSS?
Updated 2 min read6 differences
In short
SQL injection makes a server run an attacker's database commands, while XSS makes a website run an attacker's JavaScript in other users' browsers.
SQL Injection
SQL injection is an attack where user input is treated as part of a database query, letting an attacker read, change, or delete data they should not reach.
Read the page on SQL InjectionXSS
Cross-Site Scripting
XSS is a vulnerability that lets an attacker inject malicious JavaScript into a trusted website so that it runs in other users' browsers.
Read the page on XSSSQL Injection and XSS compared
| Aspect | SQL Injection | XSS |
|---|---|---|
| Injected code | SQL | JavaScript or HTML |
| Where it runs | On the database server | In other users' browsers |
| Who is harmed | The site's data and everyone in it | Individual visitors to the site |
| Typical damage | Stolen data, changed or deleted records, bypassed logins | Stolen sessions, actions in the victim's name, defaced pages |
| Main defense | Parameterized queries or an ORM | Escaping output and a Content Security Policy |
| OWASP Top 10 | Listed under Injection | Also listed under Injection |
The difference, explained
Both are injection attacks: untrusted input ends up being treated as code instead of data. In SQL injection, input such as a username is pasted into a database query, so a value like ' OR '1'='1 changes what the query does. In cross-site scripting, input such as a comment is placed in a web page without escaping, so a <script> tag or an event handler in it runs in the browser of everyone who views the page.
The difference is where the injected code runs and what it can reach. SQL injection runs on the database server and can read, change or delete data, bypass logins, and sometimes take over the machine. XSS runs in the victims' browsers with the site's privileges, so it can steal session tokens, act as the user or change what the page shows.
The defenses follow one idea: keep code and data apart, at the place where they meet. Against SQL injection, use parameterized queries or an ORM instead of building queries from strings, and give the database account only the permissions it needs. Against XSS, escape output for its context, which modern frameworks like React do by default, avoid inserting raw HTML, and add a Content Security Policy as a second layer.
A common misconception is that validating or filtering input is enough. Blocklists miss encodings and edge cases; the reliable fixes are parameterized queries for databases and context-aware output encoding for HTML, with input validation as an extra layer rather than the main defense.
Where each one is a risk
SQL Injection is a risk when…
- Code builds SQL by joining strings with user input.
- Raw queries are used where the ORM's safe methods are bypassed.
- The database account the app uses can read or change far more than it needs.
XSS is a risk when…
- Pages show user-generated content such as comments, names or profiles.
- Code inserts HTML with innerHTML or a framework's raw-HTML escape hatch.
- Search terms or URL parameters are echoed back into the page.
The vulnerable line, and the fix (Node.js)
// Vulnerable: input becomes part of the SQL
const sql = "SELECT * FROM users WHERE email = '" + req.query.email + "'";
await db.query(sql);
// Fixed: a parameterized query keeps input as data
await db.query("SELECT * FROM users WHERE email = $1", [req.query.email]);// Vulnerable: input becomes part of the page's HTML
comment.innerHTML = userComment;
// Fixed: insert it as text, so tags are shown, not run
comment.textContent = userComment;Readers ask
Which is more dangerous, SQL injection or XSS?
SQL injection can expose or destroy a whole database in one attack, so its worst case is usually bigger. XSS hits users one by one, but on a popular site it can take over many accounts.