Build fluency in the vocabulary of user input changing a SQL query's actual meaning.
0 / 5 completed
1 / 5
At standup, a dev mentions user-supplied input being concatenated directly into a SQL query string, letting an attacker embed extra SQL syntax that changes the query's actual meaning. What is this vulnerability called?
SQL injection happens when user-supplied input is concatenated directly into a SQL query string, letting an attacker embed extra SQL syntax, such as a stray quote followed by additional clauses, that changes what the query actually does, potentially bypassing authentication or exfiltrating unrelated data. Cross-site scripting instead injects a malicious script into a page rendered in a victim's browser, a different attack surface entirely. This direct-concatenation pattern is exactly what makes user input dangerous the moment it's treated as part of the query's own syntax rather than as pure data.
2 / 5
During a design review, the team requires every query with user-supplied values to use parameterized queries, or prepared statements, instead of string concatenation. Which capability supports this?
Parameterized queries, or prepared statements, send user input to the database as a separate, strictly-data parameter, so the database engine itself never interprets that value as part of the query's syntax, regardless of what characters it contains. Continuing to concatenate input directly into the query string leaves that separation entirely up to careful escaping, which is exactly the kind of manual defense that's historically proven unreliable. This parameter-versus-syntax separation is the single most effective, broadly recommended defense against SQL injection.
3 / 5
In a code review, a dev notices a search feature builds its WHERE clause by directly inserting the user's search term into the query string, with only a basic attempt to strip out single-quote characters beforehand. What does this represent?
This is an incomplete, bypassable SQL injection defense, since stripping only single-quote characters ignores the many other ways an attacker can construct a working injection payload, depending on the database engine's own syntax quirks, encoding tricks, or numeric contexts that don't require a quote at all. A parameterized query is the actual robust defense, not this partial character-stripping approach. This is exactly why ad hoc input sanitization is considered fragile compared to parameterized queries, which remove the injection risk structurally rather than trying to filter out every possible dangerous pattern.
4 / 5
An incident report shows an attacker extracted an entire user table, including password hashes, by injecting additional SQL through a login form's username field, because the query concatenated that field directly into the SQL string with no parameterization. What practice would prevent this?
Using parameterized queries or prepared statements for every query built from user-supplied input ensures injected SQL syntax in a field like a username is always treated as inert data, never as part of the query's actual structure, which closes off exactly the attack described in this incident. Continuing to concatenate that field directly into the query string with no parameterization is precisely what let the attacker exfiltrate the entire user table. This parameterization requirement is a baseline, non-negotiable defense for any application accepting user input that eventually reaches a SQL query.
5 / 5
During a PR review, a teammate asks why the team requires parameterized queries everywhere instead of relying on carefully escaping special characters in user input before concatenating it into the query string. What is the reasoning?
Manual escaping requires correctly anticipating every dangerous character, encoding, and database-specific syntax quirk that could let an attacker's input break out of its intended data context, and missing even one edge case reopens the injection vulnerability. Parameterized queries remove that ambiguity structurally, since the database driver itself keeps user-supplied values in a strictly separate data channel from the query's syntax, with no dependence on the developer correctly anticipating every attack variant. The tradeoff is essentially none here in terms of security, which is why parameterization, not escaping, is the industry-standard recommended defense.
What does the "SQL Injection Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to sql injection vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.