How to Exploit SSRF: Step-by-Step (PortSwigger Lab)

In one line

SSRF is when you make the server fetch a URL for you, then point it at things you should not be able to reach, like its own internal admin panel or cloud metadata.

What this is, for a beginner

Server-side request forgery happens when an application takes a URL or address from the user and makes a request to it from the server. Because that request originates from inside the network, it can reach places the user never could: internal-only services, admin panels bound to localhost, and, in the cloud, the instance metadata service that hands out credentials.

The attacker's goal is to control the destination of that server-side request. A feature meant to fetch a product image or check a webhook becomes a way to make the trusted server talk to internal systems on the attacker's behalf, turning a harmless-looking input into a pivot into the internal network.

The legal lab we use: PortSwigger Web Security Academy

PortSwigger provides free, legal, hosted SSRF labs. Each gives you an isolated target you are explicitly authorized to attack.

PortSwigger Web Security Academy project page →

Full walkthrough: exploiting it step by step

Step 1 — Open the SSRF lab

Start the PortSwigger lab titled Basic SSRF against the local server. It has a stock-check feature that takes a URL and fetches it server-side.

Expected result: A product page with a Check stock button that sends a URL to the server to be fetched.

Step 2 — Capture the request in Burp

Proxy through Burp and click Check stock. Find the request in Burp and note the parameter containing an internal URL that the server fetches.

Burp — stock check request

POST /product/stock
stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1

Expected result: The stockApi parameter holds a URL that the server requests on your behalf.

Step 3 — Redirect the server-side request inward

Send the request to Repeater and change the URL to point at the server's own internal admin interface, which is not reachable from your browser directly.

Burp Repeater — SSRF payload

stockApi=http://localhost/admin

Expected result: The response contains the internal admin page, delivered because the server fetched it from inside its own network.

Step 4 — Act on the internal service

Now that you can reach the internal admin panel through the server, issue a further request to perform an admin action the interface exposes, such as deleting a user, completing the lab objective.

Burp Repeater — internal action

stockApi=http://localhost/admin/delete?username=carlos

Expected result: The internal action succeeds through the SSRF channel, and PortSwigger marks the lab solved.

Step 5 — Understand the cloud escalation

On real cloud infrastructure, the same primitive is pointed at the metadata endpoint to steal credentials. Read our AWS testing material to see how an SSRF becomes full cloud account access, and try PortSwigger's cloud-metadata SSRF lab next.

Expected result: You understand why SSRF is rated so highly: in the cloud it frequently escalates from a fetch feature to credential theft.

Free resource

Get the free 35-week ethical hacking roadmap

The exact order I'd learn this in, every vulnerability and tool, week by week, with the labs to practise each one. Enter your email and I'll send it over, plus one practical lesson each week.

How to detect and fix this

How to detect it

Find any feature where the server fetches a URL or address you supply (webhooks, image fetchers, imports, stock checks) and try redirecting it to localhost or internal addresses.
Watch for differences in response and timing when pointing at internal versus external destinations, which reveal blind SSRF even when the body is not returned.
On cloud hosts, test whether the request can reach the metadata service address, the highest-impact SSRF target.

How to fix it

Do not let users supply raw URLs for the server to fetch. Where a fetch is required, validate against a strict allowlist of permitted destinations.
Block requests to internal ranges, localhost, and the cloud metadata address at the network and application layers.
Disable unneeded URL schemes and follow redirects carefully, re-validating the final destination.
Use cloud metadata protections (such as requiring session tokens for metadata access) so an SSRF cannot trivially retrieve credentials.

Common beginner mistakes

Only testing external URLs and missing the point, which is reaching internal destinations the browser cannot.
Ignoring blind SSRF because no data is returned, when timing and out-of-band signals still prove it.
Forgetting the cloud metadata angle, which is where SSRF most often becomes critical.
Testing SSRF against real third-party systems; use the isolated PortSwigger labs or infrastructure you own.

FAQ

Why is SSRF considered so dangerous?

Because the request comes from the trusted server, it can reach internal services and, in the cloud, the metadata endpoint that returns credentials. That lets a simple fetch feature escalate into internal network access or full cloud account compromise.

What is blind SSRF?

Blind SSRF is when the server makes the request but does not return the response to you. You confirm it through indirect signals such as timing differences or out-of-band interactions, and it can still be exploitable even without a visible response body.

How does SSRF relate to cloud security?

On cloud instances, pointing an SSRF at the metadata service can retrieve temporary credentials, turning a web-app bug into cloud account access. It is one of the main reasons SSRF is prioritised in cloud penetration testing.

Where to go from here

You just exploited one vulnerability in a lab. Here's the structured path.

Scattered tutorials teach you tricks; they don't make you a pentester. My mentorship is 35 weeks of exactly this, every vulnerability and tool in a deliberate order, on real labs, with one-on-one feedback on your work so your mistakes get caught early instead of becoming habits.

See the mentorship

Keep practising

How to Exploit Command Injection How to Use Burp Suite How to Exploit XXE