iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
SQL injection is only one kind of injection flaw. The others arise when untrusted input reaches a different interpreter—such as an operating-system shell, LDAP filter, expression language, or database query builder—and changes the instructions it processes. OWASP names several such forms, but it does not define an official set of “other eight.” The number in the original headline is a hook, not a security taxonomy.
The practical lesson is to look beyond SQL-specific checks: trace untrusted data to every interpreter or query language in your application, then use that component’s safe API to keep data separate from instructions.
What makes a flaw an injection vulnerability?
Injection happens when an application combines untrusted input with instructions in a way that lets the input alter the command or query being executed. The interpreter might be a database, an operating-system command processor, or a framework that evaluates expressions. The vulnerable boundary is the important part: data intended as a value is instead treated, in whole or in part, as syntax.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsOWASP’s A05 Injection – OWASP Top 10:2025 includes SQL, NoSQL, OS command, ORM, LDAP, EL/OGNL, SOAP, XPath, and REST-based query injection among its examples. Those labels are representative, not eight mutually exclusive categories. An application may use several interpreters, and the families relevant to it depend on its frameworks and data flows.
#1 Best Overall
OWASP’s 2025 category page reports 37 mapped CWEs, 1,404,249 total occurrences, and 62,445 total CVEs in its score table. It also says its dataset had more than 30,000 CVEs associated with Cross-site Scripting and more than 14,000 with SQL Injection, and that 100% of applications in the dataset were tested for some form of injection. These are OWASP’s dataset and category figures, not universal counts of every real-world vulnerability.
Which interpreters should you look for beyond SQL?
The examples below show different places where input can become syntax. They are not a complete inventory, and some labels overlap.
| Family | Interpreter or query surface | What to trace in your application | Defensive direction |
|---|---|---|---|
| NoSQL injection | A NoSQL database query | Whether request data is incorporated into a query object or expression in a way that changes its meaning. | Use the database or framework’s safe query interface; do not assume that using a NoSQL database removes injection risk. |
| ORM injection | An ORM’s query language or search expression | Whether untrusted values are concatenated into query-language text rather than supplied as values. | Use the ORM’s parameterized or structured query interface. An ORM is not automatically safe if query text is assembled unsafely. |
| OS command injection | An operating-system command or shell | Whether request data reaches command construction or execution. OWASP illustrates the risk with an `nslookup` command built by concatenating a request parameter. | Prefer an API that performs the needed operation without invoking a command interpreter; where command execution is unavoidable, use the platform’s safe argument-handling interface. |
| LDAP injection | An LDAP query or filter | Whether input is inserted into a filter or query whose syntax can be changed by that input. | Use LDAP-specific safe query construction and apply rules appropriate to the filter context. |
| EL/OGNL injection | An expression-language interpreter | Whether user-controlled values reach an expression evaluator or framework feature that interprets expression syntax. | Avoid evaluating untrusted expressions; use the framework’s safe value-binding mechanisms. |
| XPath, SOAP, and REST query injection | XPath expressions or query surfaces exposed through SOAP, REST, or related XML and web-service handling | Whether input can alter a query, retrieve data outside the intended scope, or bypass a control. | Use safe query interfaces where available and verify how each service constructs and evaluates its queries. |
The table describes review targets, not a claim that every product has an equivalent parameter-binding feature. The exact safe interface and context-specific rules depend on the interpreter and framework in use.
Why SQL defenses do not cover every interpreter
OWASP summarizes the central prevention principle this way: “The best means to prevent injection requires keeping data separate from commands and queries.” OWASP’s 2025 Injection category applies that principle broadly, but the implementation is specific to the component receiving the input. SQL parameter binding does not make a shell command, LDAP filter, XPath expression, or template expression safe.
Rank #3
For SQL, prepared statements with parameterized queries distinguish code from data and are the primary defense described in OWASP’s SQL Injection Prevention Cheat Sheet. Stored procedures can also be safe when implemented without unsafe dynamic SQL or concatenation. Table names, column names, and sort directions generally cannot be bound like ordinary values; redesign the query where possible, or map the requested choice to a finite allow-list.
Escaping is tied to a particular interpreter and context, so it is fragile as a general strategy. OWASP strongly discourages escaping all user input as the primary SQL defense. Allow-list validation can help constrain inputs such as SQL identifiers that cannot be bound, but validation alone is not a general solution for injection. The broader Injection Prevention Cheat Sheet discusses prevention across interpreter types.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to find injection paths in a codebase
Start with data flow, not a universal list of suspicious payloads. Identify sources of untrusted data, then follow them to query builders, expression evaluators, command execution APIs, and other components that interpret syntax. Review the boundary where values are constructed and passed to each sink.
- Inventory input sources. Include parameters in URLs, request bodies such as JSON, headers, cookies, and XML or SOAP inputs where the application accepts them.
- Identify interpreters and sinks. Look for database and ORM query construction, LDAP filters, command execution, XPath, and expression-language evaluation in the frameworks and services the application actually uses.
- Trace values to those sinks. Check whether input stays a value through a safe interface or is concatenated into text that the destination interprets as instructions.
- Review the surrounding controls. Confirm that authorization and other application rules still apply to the resulting query or command; a syntactically safe query can still have an access-control defect.
- Test the paths you identified. Combine source review with automated testing, including fuzzing where appropriate, and cover the relevant input surfaces and parameters.
OWASP notes that code examination can make injection flaws easier to discover than testing alone, while also recommending automated scanners and fuzzers. SAST, DAST, and IAST tools can help fit checks into CI/CD, but a scan is evidence about the paths and cases it covered—not proof that an application is free of injection.
Best Value
How to limit damage if a flaw is exploited
Least privilege does not repair an unsafe interpreter boundary, but it can constrain what an attacker can do after exploiting one. Give application and database accounts only the permissions their functions require. Avoid granting a compromised application account broader database or operating-system access than it needs.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
