mediumMultiple ChoiceObjective-mapped
PT0-002 Practice Question: A penetration tester is analyzing the results of…
A penetration tester is analyzing the results of a vulnerability scan against a web application. The scanner reports a potential SQL injection vulnerability in a login form parameter. However, manual testing with the same payload does not produce any error messages or changes in behavior. Which of the following is the most likely reason for the false positive?
⚠ Common exam trap
Many candidates assume a vulnerability scanner's report is always accurate and overlook the possibility of false positives due to input handling mechanisms like parameterized queries, instead focusing on payload encoding or scanner version issues.
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
✓
The web application is using a parameterized query that sanitizes input
The use of parameterized queries (prepared statements) separates SQL logic from user input, preventing SQL injection even if the input contains malicious payloads. The scanner's payload triggered a false positive because the application's database layer safely handles the input, so no error or behavioral change occurs during manual testing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The scanner used a payload that was not URL-encoded
Why it's wrong here
URL-encoding issues can indeed cause a scanner to send a malformed or misinterpreted payload, but this typically results in the request being rejected or the payload not being processed as intended, yielding false negatives rather than false positives. A scanner that fails to URL-encode special characters like apostrophes or semicolons would likely cause an HTTP 400 error, a WAF block, or a server-side parsing error, not a definitive SQL injection alert. The scanner reports a positive based on response anomalies that it associates with injection, and a mangled payload generally produces no such distinguishing signal. Therefore, while encoding is a common source of scanning errors, it does not explain a false positive.
- ✓
The web application is using a parameterized query that sanitizes input
Why this is correct
Parameterized queries (also known as prepared statements) separate the SQL query structure from the user-supplied data by pre-compiling the SQL statement and then binding parameters as values, never as executable code. When the scanner sends an injection payload such as ' OR 1=1 --, the database treats the entire string as a literal value, not as SQL logic, so the query executes safely and returns no error or behavioral difference. The scanner may still flag the entry point because it detects the presence of the payload in the request or a generic reflection, but the application's response remains benign, producing a false positive. This is precisely the most common reason why automated vulnerability scanners report SQL injection on modern, well-coded applications.
- ✗
The scanning engine is outdated and does not support the latest SQL syntax
Why it's wrong here
An outdated scanning engine might lack signatures or payloads for novel SQL dialects, but this causes the scanner to miss vulnerabilities, i.e., false negatives, not to invent vulnerabilities that do not exist. SQL injection detection relies on observing how the application responds to a range of payloads; if the engine does not understand a modern database's syntax, it would fail to trigger an error or a timing difference, so it would not generate a positive result. In fact, older scanners may also produce more false positives because they rely on simpler pattern matching, but that is a different flaw. Here, the premise of 'outdated' does not align with the symptom of a false positive specifically tied to SQL syntax support.
- ✗
The login form is protected by a CAPTCHA that blocks automated scanning
Why it's wrong here
A CAPTCHA's purpose is to prevent automated bots from submitting a form, so if it effectively blocks the scanner, the scanner would be unable to reach the login form at all, leading to connection timeouts, failed requests, or a 'token not found' error—not a successful SQL injection detection. Modern scanners often include CAPTCHA-solving capabilities or can disable the CAPTCHA check if it is implemented client-side, but in a strict blocking scenario, the scanner would simply report that the target is inaccessible or the test was inconclusive. Even if the scanner somehow submitted a payload despite the CAPTCHA, the application's response would reflect a CAPTCHA failure, not an SQL error, so it would not be a valid positive. Thus, CAPTCHA interference cannot generate a false positive for SQL injection.
Go deeper
Related to this question
Learn chapter
Penetration Testing Methodology
Key term
Payload
In IT and cybersecurity, a payload is the core data or malicious code delivered within a packet, file, or attack that performs the actual intended action.
Key term
False positive
A false positive is an alert or result that indicates a security threat or vulnerability exists when in fact there is no real issue.
About these practice questions
One of 185 original PT0-003 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PT0-003 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 PT0-003 exam.