Overview
SQL injection (SQLi) occurs when untrusted input is allowed to change the structure of a SQL query, letting an attacker alter what the query does. This lesson explains the concept — how injection happens — at a level focused on understanding and defense, not exploitation.
Learning objectives
- Explain the root cause of SQL injection.
- Describe how mixing code and data enables it.
- Recognize vulnerable patterns conceptually.
Core concept
SQL injection arises from a single root cause: untrusted input is concatenated into a query so that it can be interpreted as query code rather than mere data. When an application builds a query by gluing user input directly into the query string, specially crafted input can "break out" of the intended value position and add or change SQL syntax — altering the query's logic (e.g. bypassing a condition, reading unintended data). It is a specific instance of the general injection flaw: the code/data boundary is not maintained.
How it works
Consider a login that builds a query by concatenating the username and password directly into the SQL text. Because the input is placed where the database will parse it as part of the statement, an attacker can supply input that changes the WHERE condition's meaning — for example, making it always evaluate true, or appending additional clauses. The database, unaware of intent, simply executes the resulting statement. The vulnerability is not in SQL itself but in the application constructing queries by string concatenation with untrusted input.
Practical example
An unsafe login conceptually does: "select * from users where user = '" + input + "' and pass = '...'". Because input is placed inside the query text, crafted input can terminate the intended string and alter the logic so the condition no longer requires valid credentials. (In an authorized lab you would observe the query's behavior change; here the point is the pattern — direct concatenation of input into SQL — which is exactly what makes it exploitable.) The fix, parameterization, is the next lesson.
Cybersecurity relevance
SQL injection is one of the oldest and most damaging web vulnerabilities, capable of exposing or destroying entire databases. It remains common wherever queries are built by concatenation. Recognizing the vulnerable pattern (untrusted input merged into query code) is essential for both testers — who probe inputs that flow into queries — and developers, who must eliminate concatenation in favor of parameterized queries. Understanding the concept (not payload recipes) is what enables reliable prevention.
Common mistakes
- Blaming SQL rather than the unsafe query construction (string concatenation with input).
- Thinking only login forms are affected — any input reaching a query can be a vector.
- Trying to "filter dangerous characters" instead of fixing the code/data separation (covered next).
Key takeaways
- SQL injection happens when untrusted input is concatenated into a query and interpreted as code, altering the query's logic.
- The root cause is failing to keep the code/data boundary — an instance of the general injection flaw — not a defect in SQL itself.
- Recognizing the vulnerable pattern (input merged into query structure) is key; the reliable fix is parameterization, not character filtering.
Check your understanding
- What is the root cause of SQL injection in terms of code versus data?
- Why is filtering "dangerous characters" an unreliable way to address SQL injection?