This issue came from an endpoint that looked completely harmless. It was a download API that fetched a URL on the server and returned the content. The application was protected by Akamai, and direct attempts to access internal URLs like localhost were blocked.

None

At first, it felt safe enough to ignore.

Then I tried one small change.

The Simple Bypass

Instead of sending an internal URL directly, I wrapped it inside an external redirect. The request passed through without any issues.

Akamai only inspected the first URL. Once the backend followed the redirect, there were no checks on where the request actually landed.

None

That was the entire bypass.

What I Found

When the redirect pointed to an internal port that was open, the API returned a successful response with encoded HTML. Decoding it revealed a full internal web page.

When the port was closed, the response changed to a fetch error.

Just by changing port numbers, I could clearly tell which internal services were running.

The endpoint had effectively become an internal port scanner.

Confirming SSRF

To make sure this was not just an edge case, I pointed the redirect to a domain I controlled. The backend request showed up immediately in my logs.

That confirmed unrestricted server side requests with redirect following.

Why This Matters

This was not just an SSRF bug. It was an infrastructure visibility issue.

The combination of redirect following and missing validation allowed:

  • Internal port scanning
  • Discovery of internal services
  • Bypassing Akamai protections
  • Access to internal web applications

Once you have internal visibility, chaining other bugs becomes much easier.

Final Takeaway

WAFs are not a security boundary. They only see the first request.

If your backend fetches URLs, you must validate the final destination, not just the input. Otherwise, a single redirect is enough to walk straight into your internal network.

Sometimes the biggest bugs come from features that look boring and safe.