Blind SSRF: Proving Impact Without Seeing a Response
Blind SSRF without a visible response: DNS and HTTP out of band signals, timing side channels, redirects, and what the report can actually claim.
Blind SSRF is the kind of bug that looks invisible until your DNS server receives a query that should never have left the backend.
The application sends the request.
The user never receives the destination response.
The interaction still happened.
Pentesting shifts from direct reading to inference.
The examples below assume a lab or an authorized penetration test.
What changes compared with regular SSRF
With visible SSRF, you send an internal URL and receive the fetched content.
Example:
1
http://127.0.0.1:8080/admin
The internal page appears in the application’s response.
Blind SSRF removes that second half.
The backend still reaches the destination, but the application may return only:
1
2
3
{
"status": "queued"
}
or:
1
Image imported successfully
The internal response never reaches the user.
Out-of-band interaction becomes the first tool
The most reliable way to detect Blind SSRF is to use an endpoint you control and monitor for interaction.
Burp Collaborator does this well.
You can also run your own infrastructure.
Example payload:
1
https://9f31c2.oast.example/ssrf-test
If the backend resolves that hostname, you may receive a DNS query.
If it completes the request, HTTP or HTTPS may appear.
That proves the input caused network activity from the server side.
DNS alone already tells a story
Suppose you receive only DNS.
That proves some component tried to resolve the hostname.
It does not prove an HTTP connection completed.
Egress filtering may block the connection.
A parser may resolve before validation.
An intermediate security scanner may have performed the lookup.
That is why I use unique subdomains for each request.
Example:
1
2
a7f2-user-avatar.oast.example
b19e-webhook-test.oast.example
Correlation becomes much cleaner.
HTTP confirms another stage
If an HTTP request arrives with backend headers, the signal becomes stronger.
You can observe User-Agent, method, path, and source IP.
Example:
1
2
3
GET /ssrf-test HTTP/1.1
Host: a7f2.oast.example
User-Agent: Go-http-client/1.1
Now we know resolution and connection occurred.
The internal reach still needs testing.
Timing works as a side channel too
Some blind SSRFs allow timing inference.
A backend request to a fast destination may finish in 100 ms.
A request toward a filtered IP may wait five seconds for timeout.
Conceptual example:
1
2
3
4
127.0.0.1:80 -> 120 ms
127.0.0.1:81 -> 118 ms
10.20.30.40:443 -> 5.1 s
10.20.30.41:443 -> 5.0 s
That may suggest different network states.
Latency is noisy.
I do not make a strong claim from one timing sample.
I repeat tests and look for consistent patterns.
Redirects can expand the SSRF
Sometimes the application allows only external domains.
You control:
1
https://redirect.oast.example/start
That endpoint returns:
1
2
HTTP/1.1 302 Found
Location: http://127.0.0.1:8080/admin
If the backend follows the redirect without validating the new destination, the external request becomes a bridge toward the internal network.
With Blind SSRF, you may still never see the response.
Timing, behavior, or side effects may remain observable.
Endpoints with side effects are dangerous
A blind SSRF may reach an internal endpoint that changes state.
Think about:
1
http://127.0.0.1:8080/reload
or:
1
http://admin.internal/jobs/run?id=7
The call may execute even without returning data to the attacker.
That can raise impact significantly.
During a pentest I use lab endpoints or reversible actions.
Triggering destructive operations just to prove SSRF creates unnecessary risk.
Cloud metadata still matters
If the application runs in cloud infrastructure, Blind SSRF may reach metadata.
Without a visible response, direct credential theft becomes harder.
Other paths may still exist if the application forwards fetched content, processes redirects, interprets the response, or produces an observable side effect.
The fetcher’s capabilities decide the route.
Can you control the method?
Can you control headers?
Can you control the body?
Are redirects followed?
Does the backend resolve DNS once or multiple times?
Each answer adds a capability.
Parsers create useful differences
URLs have a lot of syntax.
Userinfo.
IPv6.
Encoding.
Scheme.
Port.
Hostname.
Fragment.
Different libraries may interpret the same string differently.
The validator may see an external host.
The HTTP client may see another destination.
That parser differential appears often in SSRF bypasses.
Test carefully and record how the backend normalizes each form.
Where Blind SSRF hides
Any feature accepting a URL deserves attention.
Webhooks.
Image importers.
Remote PDF generation.
Link previews.
Callbacks.
Third-party integrations.
RSS feeds.
Document converters.
Configurable health checks.
The input may also appear in a header.
PortSwigger has a classic example where the backend processes Referer.
Searching only for parameters named url misses a lot of surface.
An efficient testing flow
I start with OAST.
I use a unique identifier.
I confirm DNS.
I confirm HTTP where possible.
Then I test redirects.
Then I evaluate internal addresses using safe behavioral differences.
Only after that do I build a larger impact chain.
The report should say exactly what was proven
“Blind SSRF” alone says very little.
A strong finding describes the observed signal.
Example:
1
2
3
4
5
The backend resolved a controlled hostname.
The backend established an HTTPS connection.
The connection originated from application infrastructure.
A redirect to an internal destination was followed.
The internal response was not returned to the client.
That precision helps the team fixing the issue.
Remediation
Use an allowlist when the feature knows which destinations it needs.
Resolve the hostname and validate the resulting address.
Block loopback, link-local, private ranges, and other networks the fetcher should not reach.
Repeat validation after redirects.
Restrict protocols.
Control network egress.
Keep cloud metadata hardened.
Blind SSRF becomes far less useful when the backend has minimal reach.
A DNS resolver may be the only external signal
Some networks block HTTP egress while allowing DNS through a corporate resolver.
In that case, OAST receives a DNS query from the resolver instead of the application host.
That still shows that input influenced server-side resolution.
It also reduces confidence about which machine originated the lookup.
I correlate timestamps, unique subdomains and repetition before attributing the interaction to the correct backend.
DNS rebinding changes the address after validation
An application may resolve a hostname, confirm that the address is public and then perform another resolution during connection.
If the attacker controls DNS, the second answer may point to a private address.
Defense needs to reduce that gap.
Resolving once and connecting to the validated address is stronger than validating a hostname and allowing another layer to resolve it again.
Library and architecture determine whether the technique is viable.
Timing false positives are easy to create
Job queues, retries, connection pools and DNS caches affect latency.
I therefore do not label a port open because one request was faster.
I collect multiple samples and interleave them with known controls.
If the difference disappears, the signal was noise.
Blind SSRF requires discipline because so much of the test is inference.
References
PortSwigger Web Security Academy, Blind SSRF vulnerabilities.
PortSwigger, Testing for blind SSRF with Burp Suite.
OWASP Cheat Sheet Series, Server Side Request Forgery Prevention.