Injection attacks in application security: Types, examples, prevention

What are injection attacks?

Injection attacks occur when an application sends untrusted input to an interpreter, such as a database engine, operating system shell, XML parser, or directory service, and that interpreter executes the input as code or commands instead of treating it as data.

In practical terms, injection happens whenever an attacker supplies crafted input and the application unwittingly runs it.

Injection has been a core category in the OWASP Top 10 for years and remains a major risk in the 2025 edition. As long as applications accept input and pass it to back-end components, injection vulnerabilities will remain one of the most dangerous classes of web application security flaws.

Listed below are some of the top injection attacks you need to understand and test for. 

SQL injection

SQL injection (SQLi) targets applications that build SQL queries using unsanitized user input. If user input is concatenated directly into a database query, an attacker can modify the structure of that query and change how it behaves.

Take a simple query that checks whether a user with some specified credentials exists: 

SELECT * FROM users WHERE username = 'admin' AND password = 'password';

If the application inserts raw user input directly into the query, an attacker might supply ' OR '1'='1 as the password value and any valid string as the username, resulting in the query:

SELECT * FROM users WHERE username = 'johndoe' AND password = '' OR '1'='1';

The OR condition always evaluates to true, so the query will always return results and may allow the attacker to bypass authentication.

SQL injection subtypes

• In-band SQL injection: The attacker receives results directly in the HTTP response, often using error-based or UNION-based techniques.
• Out-of-band SQL injection: Data is exfiltrated through a secondary channel such as DNS or HTTP callbacks.
• Blind SQL injection: The application does not return database output, so attackers infer data through boolean conditions or time delays.

Impact of SQL injection

In the worst case, SQL injection can result in full database compromise, exposure of customer data, credential theft, and in some cases complete takeover of the application environment. High-profile breaches, including the TalkTalk breach in the UK, have demonstrated how a single SQL injection vulnerability can lead to massive regulatory fines and reputational damage. More recently, the MOVEit Transfer attacks included a SQL injection in the exploit chain.

How to prevent SQL injection

Use parameterized queries and prepared statements, never build SQL with string concatenation, apply strict input validation, and enforce least-privilege database accounts. Stored procedures can also add an extra layer of security if used correctly.

Command injection

Command injection, also known as OS command injection or shell injection, occurs when unsanitized user input is passed directly to a system shell or operating system command and executed.

For a conceptual example, say an application calls the underlying operating system’s ping command with raw user input:

ping $user_input

If a user provides not only a valid value but also an OS command, a vulnerable application may execute that command, so given input like 127.0.0.1; cat /etc/passwd, the server would first call the ping utility and then list the password file:

ping 127.0.0.1; cat /etc/passwd

Impact of command injection

Command injection can lead to remote code execution, server takeover, data exfiltration, and lateral movement inside the infrastructure. When combined with elevated permissions, it can provide attackers with direct control over the underlying host system.

How to prevent command injection

Avoid invoking shell commands from applications whenever possible, use safe APIs instead of direct system calls, strictly validate and allowlist input, and run services with minimal OS-level privileges.

Code injection

Code injection occurs when untrusted user input is inserted into application code and then executed by the runtime environment. Unlike SQL injection or command injection, which target specific interpreters such as databases or shells, code injection directly affects the programming language engine itself.

This typically happens when applications dynamically evaluate user-supplied input using functions such as eval(), exec(), or similar runtime evaluation mechanisms in languages like PHP, Python, JavaScript, or others.

To take a simplified PHP-syntax example, an insecure way to directly print user input might be:

eval("echo " . $_GET['input'] . ";");

If the input is unvalidated, an attacker can supply a call to the system() function and try to list the password file:

system('cat /etc/passwd');

A vulnerable application may then execute the system command instead of simply printing text.

Code injection vulnerabilities can also appear in template engines, expression evaluators, or deserialization routines where input is interpreted as executable code.

Impact of code injection

Code injection can lead to remote code execution (and the two are sometimes conflated), full application compromise, data exfiltration, and in many cases complete server takeover. Because the injected payload runs within the application’s execution context, attackers may gain the same privileges as the application itself, making this one of the most severe classes of injection vulnerabilities.

How to prevent code injection

Avoid dynamic code evaluation entirely whenever possible, never pass untrusted input into eval-style functions, use safe templating and serialization libraries, validate and sanitize all external input strictly, and run applications with minimal privileges to limit the blast radius if exploitation occurs.

Cross-site scripting (XSS)

Cross-site scripting occurs when untrusted input is included in a web page without proper output encoding, allowing attackers to inject and execute malicious JavaScript in a victim’s browser. While XSS is often discussed separately from classic “injection” flaws, it is fundamentally a type of injection because malicious code is injected into trusted content and executed by an interpreter – in this case the browser.

The simplest reflected XSS example starts with an application inserting unsanitized user input directly into HTML:

<h1>Search results for: $USER_INPUT</h1>

If the application doesn’t encode the output and the attacker submits:

<script>alert('XSS')</script>

the browser will execute the script instead of displaying the user input as text.

Common XSS types

• Reflected XSS: The payload is reflected immediately in the HTTP response (often via search fields or query parameters).
• Stored XSS: The malicious script is stored on the server (for example in comments or user profiles) and served to any user who loads it.
• DOM-based XSS: The vulnerability exists in client-side JavaScript that dynamically processes input and updates the DOM.

Impact of cross-site scripting

XSS attacks can lead to session hijacking, account takeover, credential theft, defacement, and unauthorized actions performed on behalf of victims. In real-world attacks, XSS is frequently used to steal authentication cookies, bypass access controls, and pivot deeper into applications. Because the malicious code runs in the context of a trusted site, users often have no indication that they are under attack.

How to prevent XSS

Apply context-aware output encoding, validate and sanitize input, use secure templating frameworks, implement Content Security Policy (CSP), and avoid unsafe JavaScript functions such as innerHTML with untrusted data.

XML external entity (XXE) injection

XXE injection targets XML parsers that allow external entity resolution. If external entities are enabled, attackers can force the application to retrieve local files or remote resources.

Here’s a sample payload that may cause a vulnerable application to open the password file on the server’s file system when it parses the external entity:

<!DOCTYPE foo [
 <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>

Out-of-band XXE

In out-of-band XXE attacks, the application is tricked into making external requests (for example over DNS or HTTP) to attacker-controlled servers via external entity resolution, which results in blind data exfiltration.

Impact of XXE injection

While many modern frameworks disable external entities by default, XXE injection can still be a risk in specific environments that rely on XML protocols. Successful XXE injection can expose sensitive files, enable server-side request forgery (SSRF), facilitate internal network scanning, and in some configurations lead to denial of service or even remote code execution. 

How to prevent XXE injection

Disable external entity resolution in XML parsers, use secure parser configurations by default, validate XML input strictly, and restrict outbound network access from application servers.

NoSQL injection

NoSQL injection affects databases such as MongoDB when applications construct queries directly from untrusted JSON input. The principle is exactly the same as for SQL injection, but instead of injecting statements into SQL queries, attackers inject operators or modify query logic for a specific NoSQL database.

As an example of MongoDB injection, if an app sends unvalidated username and password values directly to the database and maps request parameters directly to query operators, an attacker might try to submit the following payload to bypass authentication:

username[$eq]=admin&password[$ne]=foo

The [$eq] and [$ne] query operators mean equal and not equal, respectively, so the resulting query will find records where the username is admin and the password is not foo. If such code is used for authentication and the admin user exists, the attacker may be logged in as that user.

Impact of NoSQL injection

NoSQL injection can lead to authentication bypass, unauthorized access to data, and manipulation of stored records. In some applications, this can indirectly result in privilege escalation depending on how authorization logic is implemented.

How to prevent NoSQL injection

Validate and sanitize input before constructing queries, avoid directly embedding user-supplied JSON into database queries, and use parameterized or structured query mechanisms provided by the database driver.

LDAP injection

LDAP injection occurs when user input is incorporated into Lightweight Directory Access Protocol (LDAP) queries without proper sanitization. Applications that authenticate users or query directory services are common targets.

An attacker might inject LDAP-specific payloads into filters to change their logic and retrieve unauthorized directory entries (see this blog post for examples).

Impact of LDAP injection

LDAP injection can allow attackers to bypass authentication, enumerate directory information, access sensitive attributes, or escalate privileges in directory-integrated systems such as Active Directory environments.

How to prevent LDAP injection

Use parameterized LDAP queries, escape special LDAP characters properly, apply strict input validation, and enforce least privilege on directory accounts.

HTML injection

HTML injection occurs when user input is reflected directly into a web page without proper encoding. While it doesn’t necessarily involve JavaScript execution like cross-site scripting, it can still modify page structure and content.

Impact of HTML injection

HTML injection can deface applications, create fake login forms, enable phishing attacks, and manipulate user-facing content. In some cases, it can act as a stepping stone to more severe attacks such as XSS.

How to prevent HTML injection

Always apply proper output encoding based on context, validate user input, and treat all client-supplied data as untrusted.

JSON injection

JSON injection occurs when applications dynamically construct JSON responses or request bodies using unsanitized input. Improper concatenation can break JSON structure or alter application logic.

If improperly handled, any injected characters may modify the JSON object structure or affect downstream processing.

Impact of JSON injection

JSON injection is generally less severe than SQL injection but can still disrupt application logic, break API responses, or contribute to chained attacks such as cross-site scripting. In API-heavy architectures where JSON is usually the main data exchange format, even minor JSON parsing issues can have security consequences.

How to prevent JSON injection

Use safe serialization libraries, avoid manual JSON string concatenation, validate input, and enforce strict schema validation for API requests and responses.

CRLF injection

CRLF injection occurs when attackers inject carriage return (\r) and line feed (\n) characters into HTTP headers. This can manipulate how servers construct responses.

Impact of CRLF injection

CRLF injection can enable HTTP response splitting, header injection, web cache poisoning, and log poisoning. It is classified under the Injection category in OWASP and can serve as a building block for other attacks such as XSS.

How to prevent CRLF injection

Reject or properly encode carriage return and line feed characters in user input, validate header values strictly, and rely on frameworks that safely construct HTTP responses.

Email injection

Email injection, also known as email header injection or SMTP header injection, occurs when applications include unsanitized user input in email headers. It is often considered a form of CRLF injection because attackers inject end-of-line characters to add new headers.

Impact of email injection

Email injection can turn legitimate web applications into spam relays, facilitate phishing campaigns, leak sensitive data, and damage brand reputation.

How to prevent email injection

Strictly validate and sanitize email-related input, reject newline characters in header fields, and use secure mailing libraries that automatically escape header values.

Prompt injection: An AI-specific injection risk

Prompt injection is a newer type of attack that affects applications built on large language models (LLMs). Instead of targeting a database or operating system, it targets how an AI model interprets natural language instructions.

It happens when attacker-controlled text is included in an LLM prompt and causes the model to ignore its original instructions, reveal sensitive information, or produce unsafe output that the surrounding application then acts on.

Prompt injection shares the core principle of traditional injection – untrusted input influencing execution logic – but the mechanics are different. With SQL injection, you can separate code from data using parameterized queries. With LLMs, everything is text, so separating trusted instructions from user content is fundamentally harder.

Why prompt injection matters

If an LLM-backed feature summarizes documents, processes emails, or triggers automated actions, prompt injection can manipulate that behavior. It can expose private data, bypass safeguards, abuse downstream integrations, or execute connected tools. Read the prompt injection ebook for a deep dive into the varieties and risks of this injection type. 

Why injection attacks are still critical

Injection vulnerabilities consistently lead to data breaches, account compromise, and infrastructure takeover. Modern architectures, with their APIs, microservices, and cloud-native deployments, expand the number of interpreters and integration points where injection flaws can appear.

Injection attacks target the trust boundary between input and execution, and when that boundary fails, malicious hackers may find a way in. Crucially, injection is not limited to databases or any other specific type of system. Wherever user input is passed directly to a backend process, you can get injection, whether via a database query, an OS command, an LLM, an XML parser, a directory lookup, a template engine, or a logging mechanism. The specific technology may change, but the underlying flaw is the same.

The Log4Shell vulnerability is a clear illustration. In that case, attacker-controlled input embedded in application logs triggered a JNDI lookup, causing vulnerable systems to retrieve and execute remote code. Instead of more typical SQL injection or command injection, this was a case of raw input reaching an interpreter and being treated as JNDI instructions. The result was widespread remote code execution across thousands of exposed systems.

As long as applications dynamically process input (and they always will), injection attacks will remain one of the most critical web application security risks to understand, test for, and eliminate. 

How to reduce injection risk in your applications

Although long, the list provided in this article is still far from exhaustive (for example, there are many different types of template injection attacks). However, the common fundamentals for minimizing injection opportunities during development are well established:

• Separate inputs from logic using suitable mechanisms (like parameterized queries for SQL)
• Avoid building commands, queries, or filters through string concatenation
• Apply strict input validation and allowlists
• Use context-sensitive output encoding
• Disable unsafe parser and lookup features
• Enforce the principle of least privilege at every layer

Secure coding needs to be followed by systematic, automated security scanning, both static and dynamic. Static analysis can flag many insecure patterns in source code at an early stage, but runtime security testing of live applications and APIs is also essential to probe for reachable and exploitable injection points.

Conclusion: Where there’s input, there’s injection risk

Injections are not a relic of the early years of web development and security. Some injection attack vectors are on the wane (XXE injection), some are growing (prompt injection), and some have been holding their ground through the decades (SQL injections) – but wherever user input can influence how a back-end system interprets instructions, there is risk.

Understanding injection attacks and continuously testing for them in running applications remains the most practical way to reduce real-world application security exposure. To see how Invicti’s comprehensive application security platform can help your organization find injections and many other vulnerability types across frontends and APIs, request a demo.

‍