CS0-003 Vulnerability Management Practice Question
A security analyst is conducting a dynamic application security testing (DAST) scan of a REST API. The scanner reports a potential Server-Side Request Forgery (SSRF) vulnerability. The analyst needs to confirm the finding manually. Which TWO of the following techniques are most appropriate for validating SSRF?
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
✓
Submit a payload that triggers the server to send a request to an attacker-controlled external server (e.g., Burp Collaborator)
SSRF can be confirmed by making requests to internal resources (e.g., localhost) and observing responses, or by using an external collaborator service to detect out-of-band callbacks.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Submit a payload that triggers the server to send a request to an attacker-controlled external server (e.g., Burp Collaborator)
Why this is correct
An out-of-band (OAST) SSRF test uses an external callback server like Burp Collaborator to detect when the application fetches an attacker-specified URL. If a DNS lookup or HTTP hit is received, it proves the server-side component is making the request as the victim, even when the response body is not reflected to the tester. This technique is essential for blind SSRF, where the application processes the response internally without echoing it back. It also confirms the vulnerability independently of any firewall or filtering on the inbound path.
- ✓
Craft a request that causes the server to make a request to an internal IP address (e.g., 127.0.0.1) and observe the response
Why this is correct
By supplying a URL such as http://127.0.0.1/admin or http://127.0.0.1:8080, the tester forces the vulnerable server to issue an HTTP request to its own loopback interface and then transmits the resulting response to the user. This in-band test verifies SSRF because a successful reply shows the application is serving resources from an internal address, which should never be reachable externally. It also exposes sensitive internal endpoints, and the observed HTTP status/body can reveal whether URL validation is absent or bypassable.
- ✗
Inject malicious SQL queries into input fields to see if they are executed
Why it's wrong here
Injecting malicious SQL via input fields targets the database layer, not the server's outbound request handling. SQL injection exploits a failure to parameterize queries, allowing an attacker to read or modify database contents, whereas SSRF abuses a missing allowlist on URLs passed to server-side HTTP libraries. The request never causes the server to reach an alternative network location; it only manipulates the backend database. Therefore, observing a SQL error or successfully pilfered data indicates a completely different vulnerability class.
- ✗
Attempt to upload a malicious file to the server
Why it's wrong here
A malicious file upload test checks whether the server dangerously handles user-supplied content, potentially leading to arbitrary code execution or stored XSS via a crafted web shell. This is orthogonal to SSRF, which requires the target to make an outbound request to a supplied URL. Uploading a file never forces the server to connect to an internal IP or an external collaborator, and it does not verify the presence of server-side request forgery filters. The attack surface is entirely different: file storage and execution versus URL fetching.
- ✗
Modify HTTP headers to test for cross-site scripting
Why it's wrong here
Modifying HTTP headers to probe for cross-site scripting evaluates whether the application reflects user-controlled data into a page without proper encoding, leading to script execution in a victim's browser. XSS is a client-side issue, while SSRF is a server-side issue where the application itself is tricked into making network requests. Header changes might expose reflection points or header injection, but they do not cause the server to fetch internal resources or send out-of-band callbacks to the attacker. Thus, this test would not produce any evidence of SSRF.
Go deeper
Related to this question
Learn chapter
Vulnerability Scanning Techniques
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.
Key term
SSRF
A security vulnerability where an attacker tricks a server into making unauthorized requests to internal or external resources on behalf of the attacker.
About these practice questions
One of 236 original CS0-004 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 CS0-004 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 CS0-004 exam.