Post cover image

July 25, 2026

SSRF with Filter Bypass via Open Redirection

What’s the idea?

By Anubhav_bora

3 min read

What's the idea?

Some apps try to stop SSRF by checking the domain of the URL you give them. If the URL points to a trusted domain, it's allowed. If it points to something like localhost or an internal IP, it gets blocked.

Sounds safe, right? But there's a gap. The filter only checks the URL you typed in. It does not check where that URL leads after a redirect.

So if the trusted domain has an open redirect bug on it somewhere, we can use that. We give the filter a URL from the trusted domain (so it passes the check), but that URL actually redirects us to wherever we want — even an internal server.

Example. Say the app only allows URLs on weliketoshop.net. This domain has a page like:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

This page just redirects you to whatever is in path. That's an open redirect.

Now we send this as our SSRF payload:

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

The filter sees weliketoshop.net and says "fine, allowed." The server then fetches that URL, gets redirected, and follows the redirect straight to 192.168.0.68/admin. The filter never even saw the internal IP.

In short: the filter guards the front door, but not where the hallway behind it leads.

LAB:SSRF with filter bypass via open redirection vulnerability.

There's a stock checker on the product page. It calls an internal system to check stock. It's locked down to only accept URLs on the app's own domain.

Goal: make the stock checker hit http://192.168.0.12:8080/admin and delete the user carlos.

Steps

1. Capture the stock check request Open a product page, click "Check stock." Catch the request in Burp. It looks like:

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

Send it to Repeater.

None

2. Try an internal IP directly Change stockApi to http://192.168.0.12:8080/admin and send it.

It gets blocked. So there's a domain filter in place.

None

3. Look for an open redirect Browse the site normally. Look for links like "next product" or "view item." Catch that request in Burp:

GET /product/nextProduct?currentProductId=1&path=/product?productId=2

The path parameter looks like a redirect target.

None

4. Confirm it Change path to https://google.com and send it. If the response redirects you to Google, this is a working open redirect with no validation.

None

5. Chain them together Set stockApi to the nextProduct URL, but change its path to the internal admin address:

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=1&path=http://192.168.0.12:8080/admin

Send it. The filter allows it (domain looks fine), the server follows the redirect, and it lands on the internal admin page. You should see admin HTML in the response.

None

(Tip: if you don't already know the internal IP, use Burp Intruder to try different addresses, like 192.168.0.1 to 192.168.0.254, until one responds with an admin panel.)

6. Find the delete link In the admin HTML, look for something like:

/admin/delete?username=carlos

7. Delete carlos Repeat the same trick, this time pointing path at the delete link:

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=1&path=http://192.168.0.12:8080/admin/delete?username=carlos

Send it. Carlos gets deleted.

None

8. Check the lab Refresh the page. It should now say "Solved."

Why this works

Two weak bugs, chained together, become a strong one. The open redirect alone looks harmless. The SSRF filter alone looks solid. But put together, an attacker can reach internal systems that were supposed to be completely unreachable from outside.

Prevention

  • Don't trust a URL just because it belongs to an allowed domain. Also check where it redirects to, and validate that too.
  • Turn off automatic redirect-following in your HTTP client, or re-check the final destination URL after each redirect hop.
  • Better yet, use an allowlist of exact URLs or IPs the server is allowed to call, instead of just checking the domain name.
  • Fix open redirects on your own site too. They're often marked "low risk" alone, but they can be chained with other bugs like this one.
  • Block requests to internal/private IP ranges (like 127.0.0.1, 192.168.x.x, 10.x.x.x) at the network level, not just in application code. That way even if the filter is bypassed, the request still can't reach internal systems.