A05:2025 - Injection

Injection drops to position five in the OWASP Top 10 for 2025, continuing its gradual descent from the number-one spot it held through 2017 and its third-place ranking in 2021. This decline reflects the widespread adoption of parameterized queries and frameworks with built-in output encoding, but injection remains one of the most dangerous vulnerability classes when it does occur. The 2021 edition merged Cross-Site Scripting (XSS) into this category, and that consolidation continues in 2025. Testing found that 94% of applications were evaluated for injection with a maximum incidence rate of 19%.

Overview

Injection flaws occur when an application sends untrusted data to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or accessing unauthorized data. While modern frameworks have reduced the prevalence of classic SQL injection, injection as a class has diversified: template injection, expression language injection, ORM-specific bypasses, and DOM-based XSS represent evolving attack surfaces. Radar's SAST engine performs taint analysis to trace user-controlled input from entry points through the application to dangerous sinks, identifying injection paths across languages and frameworks.

What Radar Detects

• SQL injection via string concatenation. User input directly concatenated into SQL query strings instead of using parameterized queries, enabling attackers to modify query logic, extract data, or execute administrative operations.

• Parameterized query bypass. Dynamic table names, column names, or ORDER BY clauses constructed from user input that cannot be parameterized, creating injection points even in applications that use prepared statements elsewhere.

• ORM raw query injection. Unsafe usage of ORM escape hatches such as Django's raw(), Entity Framework's FromSqlRaw(), and ActiveRecord's find_by_sql() where user input is interpolated into raw SQL strings.

• Command injection. User input passed to system command execution functions (exec, system, spawn, popen, os.system, Runtime.exec) with shell expansion enabled, allowing attackers to chain arbitrary commands.

• LDAP filter injection. Unescaped user input embedded in LDAP search filters, enabling attackers to modify filter logic to bypass authentication or extract directory information.

• XPath injection. User input incorporated into XPath expressions without sanitization, allowing attackers to manipulate XML queries to access unauthorized data nodes.

• Template injection. User-controlled strings processed as templates by server-side template engines (Jinja2, Freemarker, Thymeleaf, Pug, ERB), enabling remote code execution through template expression evaluation.

• Cross-Site Scripting (XSS). Reflected, stored, and DOM-based XSS across all template engines and frontend frameworks. Radar traces user input through rendering pipelines to identify contexts where output encoding is missing or insufficient.

Related CWEs

CWE-89 (SQL Injection), CWE-78 (Improper Neutralization of Special Elements used in an OS Command), CWE-79 (Cross-Site Scripting), CWE-90 (LDAP Injection), CWE-917 (Expression Language Injection), CWE-943 (Improper Neutralization of Special Elements in Data Query Logic, NoSQL Injection).

See the CWE Reference for details.

Prevention

• Use parameterized queries and prepared statements for all database interactions. Never concatenate user input into SQL strings, even for simple queries.
• Use ORM methods that handle parameterization automatically and audit every usage of raw query methods for proper input handling.
• Execute system commands using subprocess calls with argument lists rather than shell strings. Avoid shell expansion entirely when incorporating user-supplied values.
• Apply context-aware output encoding for all user-generated content rendered in HTML, JavaScript, CSS, and URL contexts. Use framework-provided encoding functions rather than manual escaping.
• Validate input with strict allowlists where possible: expected formats, character sets, and length limits. Reject input that does not match rather than attempting to sanitize it.
• Deploy Content Security Policy (CSP) headers to mitigate the impact of XSS by restricting the sources from which scripts can be loaded and disabling inline script execution.
• Sandbox or disable template evaluation of user-supplied strings. If dynamic templates are required, use a restricted template environment without access to dangerous built-in functions.
• Escape special characters in LDAP filters and XPath expressions using the appropriate encoding functions for each technology.

Next Steps