What Is SQL Injection

SQL injection is a vulnerability in which user input is incorporated into a web application's database queries without proper handling, so that an attacker can execute arbitrary SQL statements. The damage can extend to the theft, alteration, and deletion of every piece of data in the database, and even to running operating system commands on the server. In the OWASP Top 10, SQL injection (CWE-89) falls under the Injection category: it topped the list as A1:2017-Injection in the 2017 edition, and appears as A03:2021 in the 2021 edition and as A05:2025 in the 2025 edition.

One of the earliest public writings on injecting SQL through the web is the article "NT Web Technology Vulnerabilities", published in issue 54 of Phrack Magazine in December 1998. It pointed out that another SQL statement can be appended to one built by concatenating the values entered on a web page, using the fact that MS SQL Server 6.5 allowed several statements to be executed as a batch. More than a quarter of a century after that warning, as of August 2026, the fundamental countermeasures remain clear, and yet cases where the vulnerability survives because of flawed implementation keep appearing.

Attack Principles and Types

SQL injection occurs when an application constructs SQL queries through string concatenation. For example, if a username entered in a login form is directly embedded in a query like SELECT * FROM users WHERE name = 'input', an attacker can enter ' OR '1'='1 to make the WHERE clause always true, bypassing authentication.

Main Attack Types

UNION-based: Injects UNION SELECT to retrieve data from tables that should not be accessible. Requires matching column count and types, but these can be inferred from error messages or response variations
Error-based: Intentionally triggers errors and reads database information (table names, column names, data) from error messages
Blind SQL injection: When error messages are not displayed, extracts information bit by bit using Boolean-based conditional branching or Time-based response time differences
Out-of-Band: Sends data from the database to an external server via DNS requests or HTTP requests

Automated tools like sqlmap make it possible to detect and exploit SQL injection without advanced technical knowledge.

Real-World Impact and Scope of Damage

The damage from SQL injection is not limited to stolen data.

Data theft: every piece of data held in the database, including personal information, authentication credentials, and credit card numbers, can be leaked
Data alteration and deletion: injected UPDATE or DELETE statements modify or remove data, and DROP TABLE can wipe out an entire table
Authentication bypass: manipulating the login query lets an attacker sign in as any account, including an administrator, without knowing the password
Taking control of the server: database features such as LOAD_FILE in MySQL or xp_cmdshell in SQL Server are abused to run commands at the operating system level

In the OWASP tallies behind the 2025 edition of the Top 10, SQL injection (CWE-89) is reported less frequently than Cross-Site Scripting, yet it is treated as a high-impact weakness with more than 14,000 CVEs on record. Detection by a WAF is an effective supplement, but techniques that slip past a WAF through clever encoding or inserted comments are well known, so it is no substitute for fixing the root cause.

Fundamental Countermeasures

The fundamental countermeasures against SQL injection are clear. Consistently applying an implementation that separates the structure of an SQL statement from the data closes off most attack paths. As OWASP notes, however, the vulnerability survives if the PL/SQL or T-SQL inside a stored procedure concatenates strings or runs them through EXECUTE IMMEDIATE, even when the calling code is parameterized.

Prepared statements (parameterized queries)

These separate the structure of an SQL statement from the data, so user input is never interpreted as SQL syntax. The Injection entry of the OWASP Top 10 also puts safe APIs that avoid the interpreter altogether, together with parameterized interfaces, at the top of its list. The major database access libraries all provide an equivalent mechanism, so the starting point is to replace the places where a query is assembled by concatenating strings. Note that the structural parts of SQL, such as table and column names, cannot be bound to a placeholder and are not protected by escaping either. When user input decides something like the column to sort by, fix the accepted values with an allow list. Escaping, in the few places where dynamic assembly is unavoidable, belongs in the supplementary role of covering what cannot be parameterized.

Making use of an ORM

With an ORM (Object-Relational Mapping), SQL has to be written by hand far less often, which lowers the risk of SQL injection. When the raw query or custom query features of an ORM are used, however, the same care as with prepared statements is required.

Defense in depth

Principle of least privilege: keep the permissions of the database account used by the application to the minimum necessary, and use a read-only account for read-only operations
Input validation: accept only numbers in numeric fields and only well-formed values in email fields. This is a supplementary measure and does not replace prepared statements
Controlling error messages: never show database error messages directly to users, which prevents information leaks through error-based SQL injection
Vulnerability management: catch SQL injection flaws early through regular security scans and code reviews
Dividing roles with security headers: security headers control the behavior of the browser and have no effect on SQL injection, where the query is assembled on the server side. Use them as the layer that handles the other risks lurking in the same input fields, such as XSS

Common Misconceptions

Escaping input values prevents SQL injection: Escape processing is prone to implementation errors, with gaps arising from character encoding differences and special cases. Prepared statements fundamentally separate SQL structure from data, eliminating the risk of escaping oversights. Use prepared statements, not escaping.
NoSQL databases are immune to SQL injection: While SQL injection does not occur, a similar vulnerability called NoSQL injection exists. In MongoDB, directly embedding user input in JSON queries allows injection of query operators. Regardless of database type, proper handling of user input is essential.

SQL Injection vs. XSS Comparison

SQL Injection

Targets the server-side database. Can steal, modify, and delete data. Fundamentally prevented with prepared statements. Damage affects server-side data.

XSS

Targets the client-side browser. Primary damage includes cookie theft and session hijacking. Defended with output escaping and CSP. Damage occurs in the user's browser.

SQL Injection