All three are injection flaws: untrusted data is treated as instructions by an interpreter. SQL injection runs it in the database, cross-site scripting runs it in a user's browser, and command injection runs it in the server's operating system shell. The interpreter decides the impact, the fix and how a scanner spots it.
One idea, three interpreters
OWASP's A05:2025 entry defines injection as a flaw that lets untrusted user input be sent to an interpreter, such as a browser, database or command line, which then runs parts of that input as commands. That one sentence covers all three. What differs is who runs the injected text and with whose authority.
Comparison
| SQL injection | Cross-site scripting | OS command injection | |
|---|---|---|---|
| CWE | CWE-89 | CWE-79 | CWE-78 |
| Interpreter | Database engine | Victim's browser | Server shell |
| Runs with the authority of | The application's database account | The victim's session on your site | The vulnerable application's operating system account |
| Typical impact | Read or change data, bypass login | Act as the user, read page data, deface | Run commands on the host |
| Who is attacked directly | Your data store | Your users, including admins | Your server |
| Primary fix | Parameterized queries | Context-sensitive output encoding | Avoid the shell, pass arguments safely, allow-list input |
| Common scanner signal | Error text, boolean difference, timing | Marker returned unencoded | Command output, timing, outbound lookup |
The impacts follow from the sources. OWASP says command injection executes commands on the host operating system usually with the privileges of the vulnerable application. The testing guide says stored XSS can be used to hijack another user's browser and capture information the user sees. The Top 10 notes that SQL injection is lower in frequency but higher in impact than cross-site scripting, based on more than 14,000 CVEs for SQL injection and more than 30,000 for cross-site scripting.
How the fix follows from the interpreter
The shared principle is to keep data separate from commands. The way you do that depends on where the data ends up.
- Database: use a parameterized interface so the database treats input as a value. Where a name or sort order must vary, map user input to a fixed list.
- Browser: encode data for the context it is placed in, such as an HTML body, an attribute, a script or a URL. A value that is safe in one context can be unsafe in another.
- Shell: avoid launching a shell with a built-up string. Call a library function, or pass an argument list. Limit characters with an allow-list.
Using the wrong fix for the interpreter is a classic mistake. Escaping quotes for SQL does nothing against a script payload, and encoding for HTML does nothing against a shell metacharacter. See input validation vs output encoding vs parameterized queries.
Where each one hides
- SQL: search boxes, filters, sort parameters, login forms, report builders.
- XSS: comments, profiles, search results, error pages, anywhere markup might be shown. See reflected, stored and DOM XSS.
- Command: file name fields, diagnostic tools such as ping or lookup forms, image or document conversion, archive handling. See how scanners detect command injection.
Other interpreters follow the same pattern: LDAP, XML parsers, template engines and expression languages. If you ask "where does this data end up", you can usually name the interpreter and the right fix.
Quick check
Which of the three is the most dangerous?
It depends on context. Command injection can give control of a host, SQL injection can expose a whole database, and XSS can act as any user who views the page, including admins. Rate each by what it can reach in your system.
Can one input have more than one of these flaws?
Yes. A single parameter may reach a query, be echoed to a page and be passed to a command. Each destination needs its own fix.
Safeguard's free scan at gold.safeguard.sh/scan checks the open source libraries your project depends on, which is a separate source of injection risk from your own code.
Sources
- OWASP Top 10 2025: A05 Injection
- OWASP: Command Injection
- OWASP WSTG: Stored Cross Site Scripting
- OWASP Injection Prevention Cheat Sheet
- MITRE CWE-79, CWE-89, CWE-78
Last reviewed: 19 October 2026.
