SQL injection

SQL injection arises when untrusted data changes the structure or logic of an SQL statement. A vulnerable application may construct a query by concatenating user-supplied text with fixed SQL, so characters or phrases in that text are interpreted as SQL syntax rather than as a value. The resulting condition can alter filtering, sorting, authentication checks, or other database operations.¹

The weakness is usually located at the boundary between an application and a relational database management system, not in SQL itself. It can affect web forms, search fields, application programming interfaces, desktop software, and administrative tools. The same underlying flaw may appear in SELECT, INSERT, UPDATE, or DELETE operations, although the consequences depend on the database account's permissions and the application's error handling.

SQL injection is classified by MITRE as CWE-89, “Improper Neutralization of Special Elements used in an SQL Command.”² Its defining failure is a loss of separation between code and data.

The consequences of SQL injection range from unauthorized disclosure to modification or destruction of data. An attacker may bypass an application's intended authorization logic, read records outside the normal interface, change stored information, or trigger database operations available to the compromised account.¹

Security literature commonly distinguishes in-band injection, in which results or database errors return through the ordinary application response, from blind injection, in which the application reveals little or no data and the attacker infers behavior from differences in responses. Out-of-band techniques use a separate communication path when the database and network configuration permit it. These categories describe information flow, not separate weaknesses.

Second-order injection is a less obvious variant: hostile text is stored first and later incorporated into a new query by another component. Injection can also occur in dynamically assembled SQL identifiers or clauses, where ordinary value-parameterization does not directly apply. The practical severity therefore depends on data sensitivity, database privileges, network reachability, and whether other controls limit the affected account.

Parameterized queries, also called prepared statements, are the primary defense because they send SQL structure and values through separate mechanisms.¹ Database access libraries should bind input as parameters rather than concatenate it into query strings. Object-relational mappers can help, but they do not make hand-built or dynamically generated SQL automatically safe.

When a value must determine an SQL identifier or a limited syntactic choice, applications should use a strict allowlist mapped to fixed server-side choices. Input validation is useful for enforcing type, length, range, and business rules, but it is not a substitute for parameterization. Escaping is database-specific and error-prone, so it should not be the main control.

Least-privilege database accounts reduce the damage a successful injection can cause; separate accounts, restricted schemas, protected secrets, and careful transaction design add further containment.³ Testing should combine code review, static analysis, dependency review, and controlled dynamic testing. Errors shown to users should be generic, while detailed database failures go to protected logs. An incident response should preserve relevant evidence, rotate exposed credentials, assess data integrity and access, patch the underlying query construction, and verify that the weakness is absent elsewhere.

SQL injection is not limited to public websites and is not always visible through dramatic error messages. It has appeared in internal tools, mobile and desktop applications, APIs, reporting systems, and background jobs that process imported data. A vulnerability can remain exploitable even when an interface accepts only apparently ordinary text, because unsafe data may be transformed, decoded, or reused later as a second-order input.

Stored procedures are not automatically a defense: procedures that construct SQL dynamically from untrusted values can retain the same weakness, whereas procedures that keep values bound and privileges constrained can be useful as part of a broader design.¹ Likewise, a web application firewall may block known patterns but cannot reliably replace safe query construction.

Modern development guidance treats injection prevention as part of the software lifecycle rather than a final filtering step. NIST's Secure Software Development Framework emphasizes integrating secure requirements, design, implementation, testing, and response practices throughout development.⁴ The broader lesson also applies to other interpreters: untrusted data must remain data when passed to a language processor.

Parameterized query

A query whose SQL structure is fixed separately from values supplied through bound parameters.

Blind SQL injection

Injection in which the application does not directly return useful database results, requiring behavior to be inferred from responses.

Second-order injection

An attack in which data stored during one operation is later interpreted as SQL when reused unsafely.

Least privilege

A security principle that grants an account only the permissions necessary for its task.