SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question
A security analyst is reviewing the results of a dynamic application security test (DAST) on a new e-commerce application. The report indicates that the application's product search functionality is vulnerable to blind SQL injection. The analyst is tasked with recommending a remediation to the development team. The developers currently concatenate user input directly into SQL queries. Which of the following recommendations would most effectively and permanently mitigate this vulnerability?
⚠ Common exam trap
Many candidates choose input sanitization (Option B) because they confuse escaping with proper parameterization, not realizing that escaping is a fragile, context-dependent workaround that fails against advanced injection techniques like time-based blind SQLi or multi-byte character attacks.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Replace dynamic SQL queries with parameterized prepared statements.
Parameterized prepared statements separate SQL logic from user input, ensuring that input is always treated as data, not executable code. This permanently prevents SQL injection by design, regardless of the input content, unlike input filtering or WAF rules which can be bypassed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Implement a web application firewall (WAF) rule to block suspicious SQL keywords in search parameters.
Why it's wrong here
A WAF is a compensating control that can detect and block some SQL injection payloads, but it does not fix the underlying vulnerable code. Attackers can often bypass WAF rules using encoding, obfuscation, or logic differences. This is not a permanent fix and should not be the primary recommendation.
When this WOULD be correct
In a scenario where the organization cannot modify application code (e.g., legacy system) and needs a temporary compensating control while planning a code rewrite, a WAF would be the correct recommendation to reduce immediate risk.
- ✗
Sanitize user input by escaping single quotes and other special characters before concatenation.
Why it's wrong here
Input sanitization via escaping can reduce risk but is not foolproof. Different databases have different escape characters and contexts (e.g., numeric fields, like clauses) where escaping may fail. It is possible to bypass escaping with techniques such as second-order SQL injection or using database functions. Parameterized queries are more robust.
When this WOULD be correct
In a scenario where the application uses a legacy database system that does not support parameterized queries, and the developer must manually handle input within a stored procedure that already uses parameterized calls, input sanitization might be a secondary defense.
- ✓
Replace dynamic SQL queries with parameterized prepared statements.
Why this is correct
Parameterized prepared statements ensure that user input is always treated as data, not executable code. The database compiles the SQL statement with parameter placeholders, and the actual values are bound separately. This completely prevents SQL injection because the input cannot alter the query structure. This is the industry-standard permanent fix.
- ✗
Encode all user input using HTML entity encoding before database operations.
Why it's wrong here
HTML entity encoding is designed to neutralize special characters in output that is rendered in a web browser, preventing cross-site scripting (XSS). It has no effect on SQL queries because the encoding does not change how the string is interpreted by the database. This would not prevent SQL injection.
When this WOULD be correct
This option would be correct in a question about mitigating stored or reflected XSS vulnerabilities in a web application, where user input is displayed in HTML pages and must be encoded to prevent script execution.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SY0-701 exam frequently reuses these exact scenarios with slightly different constraints.
✓Replace dynamic SQL queries with parameterized prepared statements.Correct answer▾
Why this is correct
Parameterized prepared statements ensure that user input is always treated as data, not executable code. The database compiles the SQL statement with parameter placeholders, and the actual values are bound separately. This completely prevents SQL injection because the input cannot alter the query structure. This is the industry-standard permanent fix.
✗Implement a web application firewall (WAF) rule to block suspicious SQL keywords in search parameters.Wrong answer — click to see why▾
Why this is wrong here
A WAF can block known SQL injection patterns but does not fix the root cause; attackers can bypass WAF rules using encoding or other techniques, and it does not prevent injection in all cases.
★ When this WOULD be the correct answer
In a scenario where the organization cannot modify application code (e.g., legacy system) and needs a temporary compensating control while planning a code rewrite, a WAF would be the correct recommendation to reduce immediate risk.
Why candidates choose this
Candidates may think a WAF provides a quick, easy fix without requiring code changes, overlooking that it is a detective/preventive control rather than a permanent remediation.
✗Sanitize user input by escaping single quotes and other special characters before concatenation.Wrong answer — click to see why▾
Why this is wrong here
Escaping special characters is error-prone and can be bypassed by attackers using alternative encodings or complex payloads; it does not eliminate the SQL injection vulnerability because the query structure remains dynamic.
★ When this WOULD be the correct answer
In a scenario where the application uses a legacy database system that does not support parameterized queries, and the developer must manually handle input within a stored procedure that already uses parameterized calls, input sanitization might be a secondary defense.
Why candidates choose this
Candidates often confuse input sanitization with secure coding practices, believing that escaping characters is sufficient to prevent SQL injection, without understanding that parameterized queries provide a structural separation of code and data.
✗Encode all user input using HTML entity encoding before database operations.Wrong answer — click to see why▾
Why this is wrong here
HTML entity encoding is designed to prevent XSS attacks by neutralizing HTML special characters, not SQL injection. It does not alter SQL syntax or prevent malicious SQL from being interpreted by the database.
★ When this WOULD be the correct answer
This option would be correct in a question about mitigating stored or reflected XSS vulnerabilities in a web application, where user input is displayed in HTML pages and must be encoded to prevent script execution.
Why candidates choose this
Candidates may confuse encoding techniques, thinking that any encoding of user input can prevent injection attacks, or they may overgeneralize the principle of 'sanitizing input' without understanding the specific context of SQL injection.
Analysis generated from the official SY0-701blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Application Attacks: SQL Injection, XSS
Key term
WAF
A Web Application Firewall (WAF) is a security tool that filters, monitors, and blocks HTTP traffic to and from a web application to protect it from common attacks.
Key term
Vulnerability
A vulnerability is a weakness in a system, network, or software that could be exploited by a threat to cause harm or unauthorized access.
About these practice questions
Courseiva writes every SY0-701 question from scratch — 1,013 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.