How a user-controlled URL can make the backend reach localhost, internal services, and places the browser could never access directly.
This is the last article in my Key Web Vulnerabilities series.
I started this series with practical web bugs: authentication bypass, IDOR, XSS, SQL injection, CSRF, path traversal, and file uploads. Each topic taught me something different about user-controlled input crossing a trust boundary.
SSRF feels like a good place to close this chapter because it moves the conversation one layer deeper.
After this series, I want to move into the OWASP Top 10 in a broader way. That will not be only about payloads. It will also be about design decisions, trust boundaries, logging, insecure defaults, and developer choices.
SSRF is a nice bridge into that world.
<h2>What SSRF actually means</h2>
<img src="https://media.daily.dev/image/upload/s--UN7bRBOF--/f_auto/v1782574789/ugc/content_a13ef3a1-c274-43da-b921-2a3a675cd092?_a=BAMAMicg0" alt="ChatGPT Image Jun 27, 2026, 04_30_31 PM.png">
Server-Side Request Forgery happens when user-controlled input can influence a request made by the backend server.
The key point is this:
<pre><code>The request is made by the backend, not directly by the user&#x27;s browser.
</code></pre>
A normal browser request looks like this:
<pre><code>user browser -&gt; public web application
</code></pre>
An SSRF flow looks more like this:
<pre><code>user controls input -&gt; backend receives it -&gt; backend sends request somewhere
</code></pre>
That “somewhere” is the dangerous part.
If the backend can only call known destinations, the risk is smaller. If the user can influence the destination, SSRF becomes interesting.
<h2>The stock API example</h2>
<img src="https://media.daily.dev/image/upload/s--MdrmjHre--/f_auto/v1782574811/ugc/content_194a9790-d6fc-4546-ae3e-eedfbcddcf7a?_a=BAMAMicg0" alt="ChatGPT Image Jun 27, 2026, 04_30_38 PM.png">
A classic example is a stock-checking feature:
<pre><code>POST /product/stock

stockApi=http://stock.example.internal/product/stock/check?productId=1&amp;storeId=1
</code></pre>
The application receives <code>stockApi</code>, then the backend fetches it.
If the backend trusts that URL, the attacker may try to change it:
<pre><code>stockApi=http://localhost/admin
</code></pre>
The attacker is not connecting to the internal admin panel directly. They are asking the vulnerable backend to connect to it.
That is the shape of SSRF:
<pre><code>attacker-controlled destination
 +
trusted backend network position
</code></pre>
The payload often looks like a URL, host, path, or internal destination. It is a place the server may request.
<h2>I understood backend requests. Localhost still got me.</h2>
The funny part is that I did not struggle with the idea that the backend can make requests. I had written some backend code before, and I knew those requests come from the server-side environment.
The thing that messed with my head for a moment was <code>localhost</code>.
In normal development, <code>localhost</code> is my world. My machine. My local app. My local API. My “why is port 3000 already in use again?” problem.
In SSRF, that mental shortcut breaks.
When the vulnerable app requests:
<pre><code>http://localhost/admin
</code></pre>
it is not talking to my laptop.
It is talking to the application server’s own localhost.
Same word. Completely different machine. Very different security impact.
That was the moment SSRF became much more interesting to me. It was not about a weird URL. It was about borrowing the server’s position in the network.
<h2>Why localhost matters</h2>
In many systems, internal interfaces are not meant to be public.
For example:
<pre><code>http://localhost/admin
http://127.0.0.1/admin
http://localhost:8080/metrics
</code></pre>
Those URLs may be inaccessible from the internet but reachable from the server itself.
If an internal admin interface trusts requests from localhost, and a public feature lets the attacker influence a backend request, the attacker may bypass the intended boundary.
The request comes from the trusted application server. That is the trick.
<h2>External URL vs internal URL</h2>
An external URL is publicly reachable:
<pre><code>https://example.com/image.jpg
https://api.public-service.com/data
</code></pre>
An internal URL may only be reachable inside the application’s infrastructure:
<pre><code>http://localhost/admin
http://127.0.0.1/admin
http://10.0.0.5/internal-api
http://192.168.0.10:8080/admin
</code></pre>
A user may not be able to access these targets directly, but the backend might.
That creates the SSRF risk:
<pre><code>Browser cannot reach it.
Backend can reach it.
User can influence backend destination.
</code></pre>
<h2>Regular SSRF</h2>
The easiest SSRF to understand is a non-blind SSRF.
The backend makes the request, and the response comes back to the user.
Example:
<pre><code>stockApi=http://localhost/admin
</code></pre>
If the application returns the internal admin page HTML in the response, the result is visible.
That makes the issue easier to prove: you change the backend destination, the backend requests the internal target, and the application returns the internal response.
You send a payload. You see the result.
<h2>Why SSRF is different from the previous topics</h2>
<img src="https://media.daily.dev/image/upload/s--01VdwfPn--/f_auto/v1782574914/ugc/content_04fee490-719f-4522-b79b-87877366d6e0?_a=BAMAMicg0" alt="ChatGPT Image Jun 27, 2026, 04_31_16 PM.png">
This is where SSRF made a nice final topic for the series.
Path Traversal looked like this:
<pre><code>attacker controls a file path used by the server
</code></pre>
File Upload looked like this:
<pre><code>attacker controls a file stored or processed by the server
</code></pre>
SSRF looks like this:
<pre><code>attacker controls a destination requested by the server
</code></pre>
That is a different kind of trust boundary.
The application may be doing something legitimate: fetching stock data, downloading a remote image, validating a webhook callback, generating a URL preview, importing data, or talking to another service.
The vulnerability appears when the user can steer that server-side request somewhere the application did not intend.
<h2>SSRF is not only about HTTP</h2>
Most beginner examples use HTTP because it is easy to understand:
<pre><code>http://localhost/admin
</code></pre>
But the deeper idea is not “HTTP is dangerous”.
The deeper idea is:
<pre><code>The application performs outbound communication based on user-controlled input.
</code></pre>
Depending on the technology, SSRF may involve different protocols or URL schemes. URL parsing, redirects, DNS, proxy settings, and network rules can all affect what happens after validation.
This is where the topic starts moving away from “try this payload” and toward application architecture.
<h2>A safer mental model</h2>
When reviewing a feature that fetches something server-side, I now want to ask:
<pre><code>Who chooses the destination?
Can the user provide a full URL?
Could an ID or known key be used instead?
Does the backend follow redirects?
Can the destination resolve to localhost or private IPs?
Is the response returned to the user?
</code></pre>
The safest design is usually not:
<pre><code>Give me any URL and I will fetch it.
</code></pre>
A safer design is more like:
<pre><code>Give me an ID or known key.
I will map it to an approved destination.
</code></pre>
For example:
<pre><code>supplier_123 -&gt; https://api.trusted-supplier.example/stock
</code></pre>
The user controls the business choice, not the raw network destination.
That pattern keeps coming back across this series: do not let users control the dangerous primitive directly.
<h2>Basic defensive direction</h2>
<img src="https://media.daily.dev/image/upload/s--w7dl6PLG--/f_auto/v1782574897/ugc/content_622c6a95-9781-4513-b682-005a46447280?_a=BAMAMicg0" alt="ChatGPT Image Jun 27, 2026, 04_37_57 PM.png">
For SSRF, good defence depends on the feature.
If the backend only needs to call known systems, use an allowlist of trusted hosts, domains, or service identifiers.
If the backend must fetch user-provided external URLs, the problem is harder. The application needs stricter validation, redirect controls, DNS/IP checks, network restrictions, timeouts, response-size limits, and careful response handling.
A denylist such as:
<pre><code>block localhost
block 127.0.0.1
block 169.254.169.254
</code></pre>
is not enough by itself.
Attackers may use redirects, DNS tricks, IPv6, hostnames resolving to private addresses, or parser differences.
That is why SSRF is not just an input validation problem. It is also a network and architecture problem.
<h2>Summary</h2>
SSRF is when the backend makes a dangerous request.
The attacker does not need direct access to an internal service. They only need a way to influence a trusted server-side request.
That is what makes SSRF different from many client-side or request-body vulnerabilities. The power comes from the backend’s network position.
This closes the Key Web Vulnerabilities series nicely because it points toward the next level: trust boundaries, infrastructure, service-to-service communication, and application design.
In Part 2, I will focus on blind SSRF, private IP ranges, cloud metadata endpoints, detection signals, and safer architecture.
<h2>My takeaway</h2>
SSRF did not confuse me because servers can make requests. I knew that.
It became interesting because one familiar word,<code>localhost</code>, changed meaning depending on whose machine was making the request.
My local development brain wanted <code>localhost</code> to mean my machine.
SSRF forced me to read it as:
<pre><code>localhost of the vulnerable backend
</code></pre>
That small context switch changes the threat model completely.
Same URL. Different requester. Much bigger problem.
I’m also testing a more relaxed visual style for this series. Do you like the direction? Let me know in the comments!

Whether you are developing for defenders, penetration testers, or anything in between we want to hear about it! We welcome detection engineers, vulnerability researchers, tool developers, and anyone interested in being a dev in cyber.

Cyber Devs

An introductory explanation of Server-Side Request Forgery (SSRF), covering how user-controlled input can cause a backend server to make requests to internal services like localhost, private IPs, and cloud metadata endpoints that the browser could never reach directly. The post walks through the classic stock API example, explains why localhost has a different meaning in SSRF context, contrasts regular (non-blind) vs blind SSRF, and outlines defensive strategies including allowlists, ID-based destination mapping, and why denylists alone are insufficient. Part 1 of a two-part closing entry in a Key Web Vulnerabilities series.

Key Web Vulnerabilities #8, Part 1: SSRF Is When the Server Makes the Dangerous Request