Back to scan results
What this check probes
The scanner first verifies a public canary at https://pciscan.org/robots.txt, then tests five common parameters: url, uri, fetch, proxy, and source.
Redirect following is disabled. A response that merely redirects the browser to the canary is not SSRF. The check fails only when the target response contains two known lines from the canary file that were absent from the baseline page, demonstrating that server-side code fetched and returned the remote resource.
The test uses HTTPS and a public file controlled by PCIScan. It does not request loopback or private addresses, cloud metadata services, local files, gopher:, dict:, FTP, alternate IP encodings, XXE payloads, or authenticated routes.
Because there is no unique out-of-band callback, blind SSRF that performs a fetch without returning any content cannot be detected by this public check.
Why this matters for PCI DSS
SSRF lets an attacker make requests from the application's network position. A vulnerable fetcher may reach services that are inaccessible from the internet, including management interfaces, internal APIs, databases, or cloud instance metadata.
That can expose credentials, bypass network controls, scan internal systems, or perform privileged actions. PCI DSS secure-development and segmentation requirements make strict outbound request handling especially important for systems connected to the cardholder-data environment.
A pass means these five public query parameters did not return the controlled canary content. It does not prove that every import, webhook, image fetcher, PDF renderer, callback, API, or background worker is safe.
How to fix it
Prefer a destination allowlist. If the application only needs to call known services, accept an identifier and map it to a server-controlled URL instead of accepting an arbitrary URL.
// ASP.NET Framework: allowlisted HTTPS destinations only
Uri destination;
if (!Uri.TryCreate(userValue, UriKind.Absolute, out destination) ||
destination.Scheme != Uri.UriSchemeHttps ||
!AllowedHosts.Contains(destination.IdnHost))
{
throw new HttpException(400, "Invalid destination");
}
If arbitrary public URLs are genuinely required, resolve every A and AAAA result and reject loopback, private, link-local, multicast, unspecified, and reserved addresses. Re-resolve and revalidate every redirect hop to prevent DNS rebinding and redirect bypasses.
Permit only https: where possible, disable automatic redirects, set strict time and response-size limits, remove credentials from outbound requests, and route traffic through an egress proxy. Network policy should prevent the application from reaching internal management networks and cloud metadata services even if validation fails.