Injection and SQL Injection

What an Injection Attack Is

Injection is one of the oldest and most dangerous classes of vulnerability, and it features prominently in the OWASP Top 10 (category A03:2021 — Injection). It occurs when an application takes untrusted, user-supplied data and inserts it into a command or query that is later executed. The interpreter (the database, the operating system shell, the template engine) cannot distinguish between the legitimate code written by the developer and the malicious data sent by the attacker.

The root of the problem is the mixing of code and data. When user input is concatenated directly inside an instruction, the attacker can break the intended structure and introduce their own logic. There are many variants: SQL injection, OS command injection, LDAP injection, server-side template injection (SSTI), and more. They all share the same root cause and the same family of defenses.

How SQL Injection Works

SQL injection (CWE-89) is the best-known variant. Imagine a login form where the application builds a query by concatenating the username and password the user submitted. If those values are inserted as-is into the SQL string, an attacker can introduce special characters (such as a quote) to prematurely close a text literal and then append their own SQL conditions.

Conceptually, the attacker manipulates the query so that the comparison clause is always true, thereby bypassing authentication without knowing a valid password. More advanced variants allow the use of operators like UNION to combine the results of the original query with data from other tables, thus extracting information that was never meant to be accessible. We do not include full payloads here because the goal is to understand the mechanism, not to enable abuse.

Types of SQL Injection

Not every SQL injection returns data directly on the page. It is worth knowing the three main families. In-band injection is the most direct: the results appear in the same response, for example through a detailed database error or a UNION query. It is the easiest to detect and exploit.

Blind injection occurs when the application shows neither the data nor the errors, but its behavior changes depending on whether an injected condition is true or false. The attacker infers information by observing differences in the responses. The time-based variant introduces artificial delays in the database to infer data bit by bit based on how long it takes to respond. Finally, out-of-band injection exfiltrates data through a different channel, such as an outbound DNS or HTTP request.

The Real Impact

The impact of a SQL injection can be catastrophic. In the worst case, an attacker can read the entire database: credentials, personal data, card information, business secrets. Many of the largest data breaches in history started with a simple SQL injection in a forgotten parameter.

Beyond reading, depending on the permissions of the database account, an attacker might modify or delete records, alter prices, create administrator accounts, or even, in some configurations, execute commands on the server's operating system. That is why injection is considered high severity: it combines ease of exploitation with a potentially total impact on the confidentiality, integrity, and availability of the data.

How to Prevent It

The primary and definitive defense against SQL injection is parameterized queries (also called prepared statements). With this technique, the structure of the SQL query is defined separately from the data. The user's values are sent as bound parameters, and the database engine always treats them as pure data, never as executable code. This eliminates the root cause: there is no longer any way for user input to change the structure of the query.

As additional layers of defense in depth, apply the principle of least privilege to the database account the application uses, so that even if an injection occurs the damage is limited. Use well-built ORMs or data access layers that parameterize by default, validate input with allow-lists where possible, and disable detailed error messages in production. To detect these flaws during development, tools like Burp Suite, OWASP ZAP, and SAST/DAST scanners are highly effective. Never rely on manually escaping characters as your only defense: it is fragile and error-prone compared to the robustness of parameterization.