SQL injection — SY0-701

WHAT IT IS

A SQL injection attack consists of the insertion or "injection" of a SQL query via the input data from the client to the application. (Source: OWASP, "SQL Injection.") NIST characterizes SQL injection attacks as those that "look for web sites that pass insufficiently-processed user input to database back-ends." (Source: NISTIR 7682, via NIST CSRC Glossary.)

In plain terms: an attacker supplies crafted input that the application passes directly into a SQL statement, causing the database to interpret the attacker's text as commands rather than data.

---

Mental model

SQL makes no distinction between the control plane (commands) and the data plane (values). When an application builds a query by concatenating raw user input, an attacker can escape the data context and write commands — because the database engine cannot tell the difference between a value a developer intended and a command the attacker smuggled in.

Think of it as a sentence with a blank: the developer wrote "SELECT * FROM items WHERE name = '___'" and expected a product name to fill the blank. An attacker fills it with name' OR 'a'='a — and the completed sentence now means "return every row."

---

When to use it

Exam questions pair SQL injection against cross-site scripting (XSS) because both involve injecting malicious content through user input. The distinction lies in where the payload executes and what it targets:

	SQL Injection	Cross-Site Scripting (XSS)
Payload target	Database back-end	Victim's browser / client
Manipulates	SQL query logic	HTML/JavaScript rendered in browser
Primary impact	Data read, modify, delete; auth bypass	Session hijacking, credential theft, malicious redirects
Input channel	Any field that reaches a database query	Any field reflected or stored in HTML output
Key mitigation	Parameterized queries	Output encoding / Content Security Policy

Use this table to orient yourself: if the attack manipulates a database query, think SQL injection. If it manipulates what the browser renders for another user, think XSS.

---

COMMON MISCONCEPTION

"Filtering or escaping user input is sufficient protection against SQL injection."

This is the specific trap to recognize. OWASP states that input validation allow-lists and character escaping are less reliable mitigations than parameterized queries. Stored procedures are also commonly assumed to be a complete fix — but OWASP explicitly notes that "stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks."

The root cause is architectural: any approach that still constructs a SQL string by concatenation — even after escaping — can be undermined by edge cases, encoding differences, or developer error. Parameterized queries (also called prepared statements) solve the problem structurally by separating the command from the data before the query reaches the database engine. OWASP describes parameterized queries as offering "more guarantees with respect to security" than the alternatives.

Candidates who confuse "input sanitization" with "parameterized queries" will select the wrong mitigation on scenario questions.

---

How it shows up on the exam

The cognitive target for SQL injection questions in Domain 2 is application of threat analysis and mitigation selection — not just naming the attack.

Expect scenario-based items where you read a vulnerable code pattern or an attacker's behavior description and must identify:

1. What type of attack is occurring — distinguishing SQL injection from XSS, command injection, or LDAP injection based on what the attacker is manipulating (a database query vs. another system).
2. What the attacker can accomplish — OWASP documents that SQL injection can enable reading sensitive data (confidentiality breach), modifying or deleting records (integrity compromise), bypassing authentication, altering authorization information, and in some environments executing operating system commands.
3. Which mitigation addresses the root cause — scenarios often include a list that mixes parameterized queries, input validation, stored procedures, and WAF rules. Recognizing that parameterized queries address the structural separation of commands and data is the grounded answer.

Signal phrases in question stems that point toward SQL injection: "user input passed to a database," "SQL query constructed from form fields," "authentication bypass via login form," "database error message revealed."

---

Related concepts

• Memory Vulnerabilities
• Race Conditions
• Cross-Site Scripting