SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question
A developer wants to reduce the risk of SQL injection in a new customer search form. Which two changes are the best mitigations? Select two.
⚠ Common exam trap
A common mix-up: candidates think input validation alone is sufficient, but the exam emphasizes that parameterized queries are the definitive mitigation, while validation is a secondary defense-in-depth layer.
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
✓
Use parameterized queries or prepared statements for all database access.
Parameterized queries and prepared statements separate SQL logic from user-supplied data, ensuring that input is treated as a literal value rather than executable code. This prevents attackers from injecting malicious SQL commands into the query string, as the database driver automatically escapes or binds parameters safely. This is the most effective defense against SQL injection attacks.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use parameterized queries or prepared statements for all database access.
Why this is correct
Parameterized queries and prepared statements separate SQL logic from user-supplied data by defining a query template with placeholders and binding input as parameters. The database engine then treats the bound values as literal data, never as executable code, so even malicious input containing SQL keywords or operators cannot alter the intended query structure. This is the most effective defense against SQL injection because it eliminates the mechanism the attack relies on.
- ✓
Validate and constrain user input before it reaches the database layer.
Why this is correct
Input validation and constraint checking act as a secondary security layer by enforcing an allowlist of acceptable characters, types, lengths, and ranges before data reaches the database. This can neutralize many common payloads, such as embedded quotes or semicolons, but it is not a complete solution because attackers can use encoding or alternate syntax to bypass filter rules. Combine it with parameterized queries to achieve defense-in-depth rather than relying on validation alone.
- ✗
Store the database password in the page source so the app can connect faster.
Why it's wrong here
Embedding the database password directly in page source code, whether in client-side JavaScript or server-side templates, exposes credentials to anyone with access to the file system, source repository, or a browser's developer tools. An attacker who obtains such a credential gains unrestricted access to the database, potentially leaking, modifying, or deleting all data. Credentials should be stored in secure environment variables or a secrets manager, never in code that is checked in or delivered to the client.
- ✗
Disable TLS so the application can inspect requests more easily.
Why it's wrong here
Transport Layer Security (TLS) protects data as it travels between the browser and server, preventing eavesdropping and tampering by attackers on the network. Disabling TLS leaves all traffic, including any session tokens or sensitive input, exposed to man-in-the-middle interception, which can lead to session hijacking or credential theft. However, this has no bearing on SQL injection because the injection occurs during server-side query construction, before the request is encrypted or transmitted; the two issues are entirely orthogonal.
- ✗
Allow the application to build SQL statements by concatenating raw user input.
Why it's wrong here
Building SQL statements by concatenating raw user input directly into the query string is the root cause of SQL injection. For example, an attacker can supply a value like `' OR '1'='1` to change the query's logic and bypass authentication, or add a UNION subquery to extract other tables. Because the input is treated as executable SQL, the database cannot distinguish between legitimate command structure and malicious data, making this approach completely unsafe for any user-facing application.
Go deeper
Related to this question
Learn chapter
Social Engineering Attacks
Key term
Risk
Risk is the possibility that an event or action will negatively affect an organization's ability to achieve its goals, often measured in terms of likelihood and impact.
Key term
SQL
SQL is a standardized programming language used to manage and manipulate relational databases, enabling querying, updating, and data retrieval.
About these practice questions
This SY0-701 question is part of Courseiva's 1,013-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.