SQL injection (SQLi) is a web application security vulnerability that occurs when untrusted input changes the structure or meaning of an SQL database query. Attackers may exploit this flaw to read sensitive data, change or delete records, bypass application checks, or perform unauthorized database operations. The impact depends on the vulnerable query and the database permissions available to the application.
SQLi is a type of injection vulnerability. SQL itself is a legitimate language for working with relational databases; the security problem arises when an application mixes user-controlled data with SQL instructions.
SQL Injection Definition: What Does SQLi Mean?
SQL injection means inserting attacker-controlled input into an application in a way that makes the database interpret some of that input as SQL code. For example, an insecure login form, search field, URL parameter, or API endpoint may pass input to a database through a query assembled with string concatenation. A properly constructed query treats user input as data rather than as executable SQL syntax.
The term is commonly abbreviated as SQLi. A SQL injection vulnerability is the underlying application flaw; a SQL injection attack is an attempt to exploit that flaw.
How Does SQL Injection Work?
A typical SQL injection vulnerability involves three conditions:
- An application receives data from a user or another untrusted source.
- It inserts that data directly into the text of an SQL query without safely separating values from SQL commands.
- The database executes the resulting query, which may have a different meaning from the one the developer intended.
The input can enter through forms, URL parameters, cookies, HTTP headers, JSON bodies, or other application interfaces. User input by itself is not a vulnerability. The unsafe handling of that input creates the risk.
A Simple SQL Injection Payload Example
Consider a deliberately vulnerable, MySQL-style training application that searches for a user’s record:
SELECT id, email FROM member WHERE username = '$name';
In this example, the application inserts the supplied username directly into the query string. In a controlled training environment, an input such as test' OR 1=1# can change the statement’s logic:
SELECT id, email FROM member WHERE username = 'test' OR 1=1#';
The condition 1=1 is always true, and # begins a comment in MySQL, causing the remainder of the line to be ignored. Depending on how the application processes the results, the modified query could return records beyond the intended user. This is a teaching example for an intentionally vulnerable lab, not a statement that the same syntax works against every database or application.
Why this matters: The input has crossed the boundary between data and SQL instructions. Removing suspicious characters alone is unreliable because SQL syntax differs across database systems and can be represented in many ways.
How a Parameterized Query Fixes This Example
Instead of building SQL with user-provided text, the application should use a prepared statement and bind the input as a parameter. For example, using PHP’s MySQLi interface:
$stmt = mysqli_prepare($link, "SELECT id, email FROM member WHERE username = ?");
mysqli_stmt_bind_param($stmt, "s", $name);
mysqli_stmt_execute($stmt);
$result = mysqli_stmt_get_result($stmt);
The query’s structure remains fixed. The value of $name is handled as data, even if it contains characters that look like SQL commands. Real applications also need authentication, authorization, appropriate error handling, and least-privilege database access.
What Are the Main Types of SQL Injection?
Security practitioners generally group SQL injection techniques into three categories:
- In-band SQL injection: the attacker uses the same communication channel to send input and receive results. Error-based and UNION-based techniques belong to this category.
- Blind (inferential) SQL injection: query results are not returned directly. Differences in responses or timing can reveal information.
- Out-of-band SQL injection: information is communicated through a separate channel, where the database environment permits it.
A second-order SQL injection vulnerability occurs when untrusted input is stored and later inserted unsafely into a different SQL query. It describes when and where the vulnerable data is used, rather than a separate result-transport channel.
For comparisons, examples, detection methods, and remediation guidance, read our guide to SQL injection attack types, examples, and prevention.
What Are the Risks of SQL Injection?
A successful attack may lead to unauthorized disclosure of customer information, modified business records, authentication bypass, or data deletion. In some configurations, excessive database privileges can increase the impact. An SQL injection flaw does not automatically provide administrator access or allow arbitrary commands; the outcome depends on the database, application, permissions, and available functions.
How Can SQL Injection Be Prevented?
Parameterized queries are the primary defense against SQL injection when input is used as a database value. Additional practices reduce exposure and impact:
- Use prepared statements with bound parameters instead of constructing SQL with untrusted strings.
- For dynamic column names, table names, or sort options that cannot be parameterized as values, select from an explicit allow-list of trusted identifiers.
- Give application database accounts only the permissions they require.
- Review database access code, test applications with authorization, and fix identified vulnerabilities.
- Use a web application firewall (WAF) as an additional control to detect and block many malicious HTTP requests while code fixes are developed and deployed.
A WAF cannot repair unsafe database queries or guarantee protection against every SQL injection technique. Application-level remediation remains essential. See the OWASP SQL Injection Prevention Cheat Sheet for implementation guidance.
Frequently Asked Questions
What Is the Difference Between SQL and SQL Injection?
SQL is a language used to query and manage relational databases. SQL injection is a security vulnerability in which an application allows untrusted input to alter an SQL query.
What Is an SQL Injection Payload?
An SQL injection payload is the input used to test or exploit unsafe query construction. Its syntax and effects vary by database and context. The simplified MySQL training example above illustrates how input can change a query’s intended logic.
Can SQL Injection Affect APIs?
Yes. APIs that incorporate untrusted request parameters or JSON data into SQL commands unsafely can be vulnerable, even when the application has no traditional web form.
Can a WAF Stop SQL injection?
A WAF can identify and block many SQL injection attempts at the HTTP layer, provide monitoring visibility, and support temporary virtual patching. It should be combined with parameterized queries, secure development, and vulnerability remediation.
Protect Your Applications with Defense in Depth
CDNetworks Web Application Firewall (WAF) helps inspect incoming HTTP and HTTPS requests and mitigate known and evolving web attack patterns at the edge. For a durable solution to SQL injection, pair runtime protection with secure query construction and application security testing.
Further reading: OWASP SQL Injection Prevention Cheat Sheet | NIST SQL Injection Glossary
