How callbacks, timing, private IP ranges, and cloud metadata endpoints make SSRF dangerous even without the response body.
In Part 1, I focused on the SSRF mental model: the attacker influences where the backend sends a request.
The request is server-side. The destination may be internal. The browser may never reach it directly.
Part 2 is about the version I found most interesting: blind SSRF.
Regular SSRF is easier because the response comes back to you. Blind SSRF is different: the server may make the request, but you may not see the answer.
<h2>Regular SSRF vs blind SSRF</h2>
Regular SSRF looks like this:
<pre><code>attacker controls URL -&gt; backend requests internal service -&gt; response returns to attacker
</code></pre>
Blind SSRF looks like this:
<pre><code>attacker controls URL -&gt; backend makes request -&gt; response is hidden
</code></pre>
The application might return only <code>Stock check failed</code>, <code>Request submitted</code>, or nothing useful at all.
That does not mean the backend did not make the request. It only means the response body was not reflected back.
Blind SSRF feels more like proving a side effect than reading a page.
<h2>Why blind SSRF clicked for me</h2>
Blind SSRF was the most interesting part of this topic for me because it changes the testing mindset.
With many earlier vulnerabilities, the app gives direct feedback: SQL injection changes data, XSS executes script, path traversal returns file content, or file upload exposes a stored file.
With blind SSRF, the app may stay quiet.
You are not only asking:
<pre><code>Can I see the internal response?
</code></pre>
You are asking:
<pre><code>Did the backend make an outbound request at all?
</code></pre>
That is a different kind of proof.
It feels less like opening a door and more like placing a bell somewhere and waiting for the server to ring it.
<h2>Out-of-band evidence</h2>
<img src="https://media.daily.dev/image/upload/s--3vWsMT_i--/f_auto/v1782656016/ugc/content_c52f563b-c82c-4ee6-aa77-cfb0c40c261e?_a=BAMAMicg0" alt="16c3fd84-6b83-44d1-b8d1-6435a6f3c274.png">
Blind SSRF is often tested with out-of-band evidence.
Conceptually, the flow is:
<pre><code>attacker-controlled callback URL
 ↓
vulnerable backend requests it
 ↓
callback server records the interaction
</code></pre>
The application may not show the response, but the external listener sees that the backend connected. That proves one thing:
<pre><code>The backend made a server-side request to a destination I controlled.
</code></pre>
In labs, tools such as Burp Collaborator are often used for this. The important idea is that evidence comes from outside the app’s normal response body.
Other clues can include timing differences, error messages, status codes, DNS lookups, HTTP callbacks, or logs in a controlled service.
Blind SSRF is still SSRF. It is just less chatty.
<h2>Private and internal IP ranges</h2>
SSRF becomes dangerous because the backend may reach places that are not public.
Important ranges include:
<pre><code>127.0.0.0/8 loopback / localhost
10.0.0.0/8 private network
172.16.0.0/12 private network
192.168.0.0/16 private network
169.254.0.0/16 link-local addresses
</code></pre>
A public user may not reach these addresses. The backend might.
SSRF is not only about one vulnerable parameter. It is about what the application server can see from inside the network.
<h2>Cloud metadata endpoints</h2>
The link-local address that appears again and again in SSRF discussions is:
<pre><code>169.254.169.254
</code></pre>
In cloud environments, metadata services may expose instance information and, depending on the platform and configuration, credentials or role-related data.
That does not mean every SSRF becomes cloud compromise. Modern metadata protections reduce risk, including session-token based metadata access.
But the idea is important: the backend may be close to sensitive infrastructure-only services. If user input can steer requests there, the impact can be much bigger than reading one internal page.
<h2>Internal reconnaissance</h2>
<img src="https://media.daily.dev/image/upload/s--1_27Oph2--/f_auto/v1782656662/ugc/content_8d58be89-2fe8-469d-88f0-b1d162f357c2?_a=BAMAMicg0" alt="da767acd-6151-485b-add4-85bc7dc0bae4.png">
Even when SSRF does not return sensitive data, it may help map internal systems.
Different destinations may produce different behaviours: connection refused, timeout, fast error, slow error, different status, different response size, or different DNS behaviour.
Those differences can reveal whether a host exists, a port is open, or a service behaves differently.
An attacker may not need to read the response body to learn something useful about the internal network.
<h2>Redirects can reopen the door</h2>
A feature may try to allow only external URLs, but if the backend follows redirects, the first URL might redirect to an internal address.
The validation may check the first destination, while the HTTP client follows the second one.
That creates a dangerous split:
<pre><code>validated URL != final requested URL
</code></pre>
This should feel familiar from Path Traversal: checking the original value is not enough if the final destination can change.
<h2>DNS and parser surprises</h2>
<img src="https://media.daily.dev/image/upload/s--F9BJSuxe--/f_auto/v1782656902/ugc/content_fbfb2330-54b1-4d31-aa5d-3983d913b824?_a=BAMAMicg0" alt="4beb677c-5743-4cc7-853b-bc084357fe9f.png">
SSRF defence gets messy because URLs are not as simple as they look.
A backend may need to handle hostnames resolving to private IPs, DNS changes, IPv6, encoded IP formats, redirects, parser differences, and mixed schemes.
This is why “just block localhost” is weak. Validate the final destination, not only the original hostname, and use network egress rules where possible.
<h2>Safer design patterns</h2>
The best defence depends on the feature.
If the app only needs known services, do not accept arbitrary URLs. Use identifiers such as <code>stockserviceprimary</code>, map them server-side, and verify the destination against a strict allowlist.
If the app really needs user-provided external URLs, such as webhooks or previews, it needs layers: safe parsing, required schemes only, blocked local/private/link-local/metadata ranges, final IP checks, redirect controls, timeouts, response-size limits, restricted egress, and logging.
This is not “one regex and done”. It is an architecture decision.
<h2>Regression tests I would add</h2>
For an SSRF-prone feature, I would test:
<pre><code>http://localhost/
http://127.0.0.1/
http://[::1]/
http://10.0.0.1/
http://172.16.0.1/
http://192.168.0.1/
http://169.254.169.254/
allowed URL that redirects to localhost
hostname that resolves to private IP
unsupported schemes
slow or huge responses
</code></pre>
I would also test normal allowed behaviour, because broken integrations quickly create risky exceptions.
The better question is not only “did the request fail?” It is “did the backend avoid making an unsafe outbound request?”
<h2>What to log</h2>
SSRF also connects nicely with logging and alerting.
Useful logs include the feature name, user/account ID, destination key, normalized URL, resolved IP, redirect chain, timeout reason, response size, and blocked/allowed decision.
Blind SSRF is harder to prove from the outside. Good telemetry makes it easier to detect from the inside.
This is one reason OWASP Top 10 feels like the right next step. Logging, design, access control, and misconfiguration decide whether SSRF is prevented, detected, or missed.
<h2>Summary</h2>
Blind SSRF is when the backend calls, but you do not see the answer.
That makes the vulnerability harder to prove, but not harmless.
Evidence may come from callbacks, DNS interactions, timing, errors, or internal logs. Impact depends on what the backend can reach: localhost-only services, internal APIs, private IPs, cloud metadata, or other infrastructure systems.
The safest approach is to avoid arbitrary destinations where possible. Use allowlisted service identifiers, validate final destinations, control redirects, block internal ranges, restrict egress, and log outbound behaviour.
<h2>Closing the series</h2>
<img src="https://media.daily.dev/image/upload/s--LMNTC4pY--/f_auto/v1782657789/ugc/content_9ba23840-9a76-4502-a868-03b3cf57b4fc?_a=BAMAMicg0" alt="429d5d03-3d2f-41c6-b356-a5e6e106bf0f.png">
This article closes my Key Web Vulnerabilities series.
The next step is OWASP Top 10, but I want to approach it in a broader way. It will not be only about payloads or individual bugs. It will also be about design, trust boundaries, logging, error handling, authentication decisions, insecure defaults, and the security impact of choices we make while building software.
That feels like the right next step after SSRF.
SSRF is already less about one suspicious parameter and more about how the application is connected to the world around it.
<h2>My takeaway</h2>
Blind SSRF was the part that interested me most because it forced a different question.
Not:
<pre><code>Can I see the response?
</code></pre>
but:
<pre><code>Can I prove the backend made the request?
</code></pre>
That shift is small but important.
SSRF is not just about sending a weird URL. It is about trust, network position, and the hidden paths an application can take when it talks to the systems around it.
Same backend. Different destination. Completely different risk.

Squad is established to Post content related to web developement.

Web Developement

A deep dive into blind SSRF (Server-Side Request Forgery), explaining how it differs from regular SSRF in that the server makes requests but the response is hidden from the attacker. Covers out-of-band detection techniques using callback servers and DNS interactions, private IP ranges and cloud metadata endpoints (169.254.169.254) as high-value targets, internal network reconnaissance via timing and error differences, redirect-based bypasses, and DNS/parser edge cases that weaken naive defenses. Includes practical regression test cases, logging recommendations, and safer design patterns such as allowlisted service identifiers and final-destination IP validation.

Key Web Vulnerabilities #8, Part 2: Blind SSRF Is When the Server Calls, but You Do Not See the Answer