Overview
Almost every web application stores its data — users, posts, prices, sessions — in a database, and it talks to that database using SQL (Structured Query Language). Before you can understand SQL injection, you need a clear picture of what a SQL query actually is and how an application builds one from user input. This lesson lays that groundwork in a safe, authorized-practice context. The single most important idea here is the boundary between code (the instructions the database executes) and data (the values those instructions operate on). SQL injection is, at its heart, what happens when that boundary breaks down.
Learning objectives
- Explain what SQL is and why applications rely on it.
- Describe how a query is structured and how user input is meant to fit into it.
- Distinguish between the code part of a query and the data part.
- Recognize how insecurely combining the two sets the stage for injection.
Core concept
A query is an instruction sent to a database engine, written in SQL. A typical query names an action (such as SELECT to read rows), the table to act on, and a condition that filters which rows are affected. For example, "give me the row from users where the username equals alice."
The crucial distinction is between two kinds of things inside a query:
- Code — the SQL keywords and structure (
SELECT,FROM,WHERE, quotes, operators) that tell the engine what to do. - Data — the specific values the query operates on (a username, a search term, an id) that are supposed to be inert content, not instructions.
When an application handles a request, it usually needs to insert user-supplied data (a login name, a search box entry) into a query. The intended meaning is: "treat this value as pure data." The vulnerability appears when the application builds the query in a way that lets user input change the code instead of merely filling in the data.
How it works
Consider a login feature. The application wants to look up a user by the name typed into a form. A query to do that looks like:
SELECT id, username FROM users WHERE username = 'alice';
Here the code is SELECT id, username FROM users WHERE username = '...' and the data is alice. The single quotes mark where a string value begins and ends — they are the fence that separates data from code.
Now look at how a naive application might build that query by gluing strings together with the user's input:
query = "SELECT id, username FROM users WHERE username = '" + userInput + "'"
If userInput is alice, the result is exactly the safe query above. The application is trusting that whatever the user typed will stay inside the quotes and behave as data. But nothing enforces that trust — the database receives one flat string of text and parses the whole thing as SQL. If the user can supply characters that close the quote early (like a ') and add their own SQL, they escape the data slot and start writing code. That is the essence of injection, explored in the next lesson.
Practical example
Imagine an authorized CTF web challenge with a product-search page. You type a search term and the app returns matching products. Behind the scenes the app builds:
SELECT name, price FROM products WHERE name LIKE '%widget%';
The widget came from your search box. In the intended flow, your term is just data inside the LIKE pattern. To confirm you understand where the data slot is, you might search for the literal term flag and watch the query become:
SELECT name, price FROM products WHERE name LIKE '%flag%';
Nothing dangerous has happened yet — you have only observed that your input lands inside a string literal in the query. Recognizing exactly where your input is placed, and whether it sits inside quotes, is the first analytical step in every SQL-injection challenge. In this lesson we stop at understanding structure; later lessons cover what it means when that placement is unsafe.
Cybersecurity relevance
SQL injection has been one of the most common and damaging web vulnerabilities for decades, appearing repeatedly on the OWASP Top Ten as part of the broader Injection category. Understanding query structure matters for both attackers and defenders:
- Defenders who understand the code/data boundary can see immediately why concatenating user input into a query is dangerous and why parameterized queries (covered later) fix it.
- Testers who understand query structure can reason about where their input lands and whether it can influence the query's logic.
Every SQL-injection technique you will learn is ultimately about one thing: whether user-controlled data can cross the line and be interpreted as code. Getting this mental model right now makes everything that follows straightforward.
Common mistakes
- Confusing code and data. Assuming that because a value "is just a search term" it can never affect the query — the database only sees the final assembled string.
- Thinking the quotes protect you. Quotes only mark boundaries in well-formed input; user input containing quote characters can break out of them.
- Ignoring where input lands. Not tracing exactly which part of a query a given input feeds into, so you cannot reason about its impact.
- Believing injection requires exotic input. The mechanism is ordinary: a single quote character is often enough to disturb a concatenated query.
Key takeaways
- Applications use SQL to read and write data in a database, building queries that combine fixed code with variable data.
- The core security boundary is between code (SQL keywords and structure) and data (the values, meant to be inert).
- Naive applications build queries by concatenating user input directly into the SQL string, trusting input to stay within the data slot.
- SQL injection arises when that trust is misplaced and user input can cross from the data slot into the code — the foundation for the rest of this module.
Check your understanding
- In the query
SELECT * FROM users WHERE username = 'alice', which parts are "code" and which are "data"? - Why does building a query by concatenating user input into a string place trust in the input that nothing actually enforces?
- What single character most commonly disturbs a naively concatenated string query, and why?