SSRF Explained Like You Are Five (For Bug Bounty Beginners)

SSRF stands for Server Side Request Forgery. It sounds scary. The idea is simple. You trick a server into making a request for you, to a place it should not go. When it works it pays big, often thousands of dollars, because it can reach systems hidden behind the company firewall.

The everyday version

Imagine a website with a feature that fetches an image from a URL you give it. You paste a link to a cat photo. The server downloads it and shows it. Normal. Now instead of a cat photo, you give it a link to the company own internal address, something only reachable from inside their network. If the server fetches that for you and shows the result, you just made the server talk to a place you could never reach yourself. That is SSRF.

Why it pays so much

The internet has a public side and a private side. You live on the public side. Servers often live on both. Inside the private side are admin panels, databases, and cloud metadata services that hold secret keys. A server with SSRF is a bridge. The classic target is the cloud metadata endpoint, a special internal address that can hand out temporary credentials. Reach that and you can sometimes take over the whole cloud account. That is why a clean SSRF often pays five figures.

Where to look for it

Anywhere the app takes a URL or fetches something for you. Image from URL features. Webhook settings. PDF generators that load a page. Link preview generators. Import from URL buttons. Any place you hand the server an address and it goes and gets something.

How to test it safely

Set up a server you control that logs every request it receives. Free tools exist for exactly this. Put your logging URL into the target feature. If your server gets a hit from the target IP, the server is making requests on your behalf. That is the first proof. Then try pointing it inward. Localhost. Internal IP ranges. Stay strictly inside program scope and rules. Some programs forbid hitting cloud metadata. Read first.

The beginner trap

Do not report blind SSRF with no impact as if it were critical. A server that pings your logger but cannot reach anything useful is a low finding. The money is in showing real internal access. A redacted screenshot of internal data is what turns a small report into a big one.

Start simple

You will not chain a full cloud takeover in week one. Start by finding any feature that fetches a URL. Point it at your logger. Confirm the server bites. That single skill, spotting the fetch and proving the callback, is the foundation every big SSRF is built on. Find the fetch. Prove the callback. Then push inward, carefully, in scope.