What Is SQL Injection?

SQL injection is a web application security vulnerability in which an attacker inserts or "injects" malicious SQL statements into an input field that is passed unsanitized to a database query, causing the database to execute commands the developer did not intend. The attack exploits the failure to distinguish between data provided by a user and the SQL control instructions surrounding that data. Because structured query language (SQL) makes no inherent distinction between its data plane and its control plane, a string of characters submitted through a login form or search box can, if not properly handled, alter the logic of the query, bypass authentication, retrieve unauthorized records, modify stored data, or in some configurations execute operating system commands. SQL injection is documented by OWASP as one of the longest-standing and most consequential classes of web application flaws.

SQL injection was identified as a significant threat in the late 1990s alongside the first generation of database-backed web applications. Its persistence reflects the structural gap between how web forms were designed and how SQL query construction was implemented: many early frameworks concatenated user input directly into query strings. The OWASP Top 10 2025 list classifies injection flaws as a high-priority risk category, noting that SQL injection specifically has accumulated more than 14,000 CVE entries across affected software over the years. The vulnerability appears across virtually every database platform, including MySQL, PostgreSQL, Microsoft SQL Server, Oracle, and SQLite, because the flaw resides in the application layer rather than in any specific database engine.

Attack Mechanism

A SQL injection attack works by inserting SQL syntax into a field the application treats as a data value. Consider a login query assembled as the string: SELECT * FROM users WHERE username = ' followed by whatever the user typed, followed by '. If a user types ' OR '1'='1, the resulting query becomes a condition that is always true, returning all rows and bypassing authentication. The attack relies on the interpreter executing the injected fragment as SQL rather than treating it as a literal string. Once an attacker establishes that injection is possible, they can use the database's own syntax to enumerate tables, extract schema information, retrieve rows from any accessible table, or issue data modification commands. The NIST glossary definition of SQL injection formally characterizes it as an attack technique used to exploit insufficient validation of user-supplied input.

Types of SQL Injection

SQL injection attacks are grouped by how the attacker receives feedback from the database. In-band injection returns query results directly in the application response, making it the most direct form: the attacker reads extracted data from the page the application renders. Error-based injection uses database error messages to infer schema and data, since a database error triggered by a malformed query often includes table names, column names, or data type information. Blind SQL injection operates without visible feedback: the attacker asks the database a series of true-or-false questions and infers information from whether the application's response changes, a process that can systematically extract an entire database through automated tooling, though slowly. Time-based blind injection is a variant in which the attacker uses conditional time-delay functions to distinguish true from false answers when application output is identical in both cases.

Prevention Techniques

The primary defense against SQL injection is the use of parameterized queries, also called prepared statements. In a parameterized query, the SQL statement structure is sent to the database separately from the user-supplied values, so the database treats the values as data regardless of their content. Stored procedures compiled on the database server provide similar protection when they do not themselves dynamically construct SQL strings. Input validation using allowlists of expected characters provides a secondary defense layer. Least-privilege database account configurations limit the damage an attacker can do even if injection succeeds: an account with read-only access cannot execute data deletion or system commands. Web application firewalls can detect and block known injection patterns as a defense-in-depth measure, though they are not a substitute for fixing the underlying query construction.

Applications

SQL Injection countermeasures have applications in a wide range of security engineering contexts, including:

• Web application penetration testing to identify vulnerable query construction patterns before deployment
• Secure software development training programs that teach parameterized query construction
• Database access control reviews to enforce least-privilege principles
• Security information and event management systems that detect injection attempts from query logs
• Static code analysis tools that flag dynamic SQL construction as a potential vulnerability during code review