From a URL Input Box to Roaming the Internal Network: A Bug Bounty Hunter's SSRF Methodology

Disclaimer: This article is intended only for authorized testing and self-built lab environments. Do not test or exploit any system without authorization. When doing Bug Bounty work, always respect the program's scope, rate limits, and disclosure policy.

Why You Should Care About SSRF

You're testing a social platform and notice a feature that automatically generates a preview card whenever you paste a link. You drop in a URL, and the server dutifully goes off to fetch the page title and thumbnail for you.

The question is: the server made that request on your behalf, but is there really any restriction on "where it's allowed to fetch from" and "which schemes it's allowed to fetch with"?

That's the heart of Server-Side Request Forgery (SSRF): when a server initiates an outbound request based on user input, but fails to properly validate the target address, an attacker gets a chance to make the server reach unintended resources (internal services, cloud metadata, local files, and so on). In Bug Bounty, SSRF is often not the finish line but an amplifier: it turns things that were once untouchable from the outside into assets you can reach indirectly.

This article is written for Bug Bounty hunters and focuses on two things:

1. How to systematically find SSRF
2. How to assess the blast radius, pushing "I can make a request" into "here's a concrete risk"
   Along the way it also explains, from a defensive angle: why certain designs tend to breed SSRF, and how to fix them.

Which Features Hide SSRF

URL previews aren't the only place SSRF shows up. Any feature that makes the server "go fetch something based on your input" deserves suspicion, especially when the outbound fetch happens on the backend and you control the target address.

Common high-risk feature points:

1. URL Preview / Link Unfurling
   Forums and CMSes have this: you paste a link, the server goes and fetches Open Graph or other meta (like og:title, og:image) to render a card. The server is expected to fetch external resources in the first place, but if there's no restriction on where it can fetch from, it turns into SSRF.
2. Image Processing / Thumbnails / Format Conversion
   A user supplies an image URL, and the backend crops, filters, or thumbnails it. As long as the backend "fetches the URL for you," it can become SSRF.
   Also watch out for SVG: SVG is fundamentally an XML/vector format that can reference external resources. If the backend parses, renders, or converts it, it can easily become a trigger point for unintended outbound requests.
3. PDF Generation / Web-to-PDF
   "Enter a URL and turn it into a PDF" is a disaster zone. If the backend rendering engine processes full HTML/JS or loads external resources, an attacker may be able to trigger requests to arbitrary URLs through attacker-controlled content and have the results rendered into the PDF and exfiltrated (depending on the engine and its restrictions).
4. Webhook Configuration / Third-Party Integrations
   SaaS platforms often let you fill in a URL that the server actively hits when an event fires. As long as the target address is controllable and there's no strict allowlist, it can be SSRF. Worse, some platforms show a response summary in the delivery log, turning a blind SSRF into one with reflected output.
5. OAuth / OpenID Connect (OIDC)
   The server needs to go to the authorization server to grab tokens, fetch the discovery configuration, or fetch keys (like jwks). If the discovery URL, token endpoint, or key endpoint is indirectly controlled from the user side (or can be redirected/injected), it can form SSRF or a multi-stage SSRF risk.
6. RSS / Feed Import
   A user supplies an RSS/Atom URL, the server fetches and parses the XML. Here you can find both SSRF and XXE attack surface at once, and it's often worth evaluating them together.

Quickly Locating SSRF Entry Points

Do your first pass of triage in the most time-efficient way possible:

1. Parameter-level search (HTTP history / crawler results)
   The keywords usually look like this:
   url, uri, href, src, redirect, callback, fetch, preview, proxy, load, endpoint, dest, target, link, feed, webhook, import
2. UI/feature-level scan
   Prioritize looking at:
   integrations, notifications, import/export, preview, media processing, document generation, webhook management
3. A very intuitive test
   If some parameter's value is a full URL (including a scheme), or looks like it will be used by the backend to fetch a resource, it's worth digging into.

The Power of URL Schemes: Why SSRF Is About More Than "Hitting HTTP"

Many people discussing SSRF fixate on http/https, but what really blows up the blast radius is how much the backend supports URL schemes and how it restricts them.

1. http:// / https://
   The basic case. If the server doesn't restrict the target of outbound requests, an attacker may be able to probe internal services, reach restricted management interfaces, or, in a cloud environment, try to reach the metadata service on a link-local address.
   The key point: whether this leads to credential or sensitive information exposure depends on the cloud platform's protections (for example, whether a token is enforced, whether there's network-layer blocking, and whether the application can read and return the content).
2. file://
   If the backend URL client supports the file scheme (or has similar local-resource loading capability), SSRF can escalate into a local file read risk, equivalent to Local File Inclusion. What you can actually read depends on execution permissions, sandboxing, path restrictions, and reflection capability.
3. gopher://
   If the environment supports gopher (many modern environments actually disable or don't support it), the danger is that SSRF may escalate from "fetching HTTP resources" into "arbitrary interaction risk with internal TCP services."
   When unauthenticated or misconfigured services exist on the internal network (for example, a management interface lacking authentication, a caching service, a database, or an internal agent) and network isolation is insufficient, the potential impact can escalate all the way from data leakage to high-risk operations (worst case including arbitrary command execution). Whether the worst case is reachable depends on the service's own configuration and network segmentation.

Defensive takeaway: if the business only needs to fetch HTTP(S), hard-restricting the scheme allowlist to http/https at the code level is the most basic and cost-effective single cut you can make. It directly slams the door on a large class of high-risk exploitation paths.

A Methodology for Confirming SSRF

Think about this with one core goal in mind: you're not "running through a checklist," you're answering three questions

1. Does the server actually send a request?
2. Does the request result come back into your hands?
3. At worst, what can it reach and what consequences can it cause?

Step 1: Confirm the Server Sends a Request

Once you've found a suspicious URL parameter, first confirm the outbound behavior.

The most reliable approach is Out-of-Band (OOB) verification:

• Point the target URL at an endpoint you control or an OOB platform (for example, Burp Collaborator or interactsh)
• Watch for a DNS query, HTTP request, or a callback at some other protocol layer

Once you can confirm "the request was sent by the target server," you've turned SSRF from a guess into a fact.

Note: some scenarios involve caching, asynchronous processing, delayed fetching, or fetching only under specific conditions (for example, only fetching images, or only allowing a specific content-type). What you need to do is patiently work out the trigger conditions.

Step 2: Determine the Reflection Type (This Step Decides Your Exploitation Room)

Two typical forms:

1. Reflected (Non-blind)
   The content the server fetches appears in the response in some form, or is otherwise observable to you:

• The URL preview directly displays the title/description/thumbnail
• Image processing renders/returns the fetched image
• PDF generation renders the result into the PDF
  This is the most valuable case, because you can see the content of the resource the server accessed, or at least see the difference.

2. Blind
   The response only tells you success/failure with no content. In that case, switch to indirect evidence to infer:

• Response differences: different targets may produce different status codes, response sizes, or error messages
• Timing differences: different targets may produce different latency (connection timeout, immediate rejection, normal response)
• DNS inference: even if the HTTP responses are identical, whether a DNS query occurred can still provide a clue

Step 3: Assess the Blast Radius (The Key to Whether the Bug Bounty Holds Up)

Once you've confirmed SSRF exists, the next step is not "start scanning immediately" but to answer the impact question with the lowest-cost method possible, so you can write a report with weight.

Questions you can try to answer:

1. Can you reach the cloud metadata service (or other sensitive link-local endpoints)?
   If you can obtain cloud identity credentials or other sensitive information, the severity may jump straight up (but always act within scope and the program's allowed limits).
2. Can you access internal management interfaces or internal APIs?
   The point isn't "you can connect to it," but "does it constitute unauthorized access" or "can you obtain sensitive information."
3. Is there a local file read risk (only when the environment/client supports the relevant capability)?
   If the application reflects or renders the fetch result, the risk becomes more concrete.
4. Can you interact with non-HTTP services (again depending on scheme/client support and network isolation)?
   This is usually a high-risk escalation path, but also the most dependent on environmental conditions.
5. Are the response differences enough to infer asset existence?
   Even if you can't see the content, as long as you can reliably infer "a certain service exists / a certain resource exists," you may raise the risk assessment (while being careful not to cause excessive probing or violate the rules).

Key line: the bigger the blast radius, the higher the value of the report. Conversely, if all you can prove is "the server hit my OOB" without demonstrating any further risk, many programs will rule the impact insufficient.

Blind SSRF: The Harsh Reality of Bug Bounty

Many programs mark blind SSRF as Informational, or even N/A outright. The reason is pragmatic: reviewers need to see provable impact.

To write a report with weight for a blind SSRF, the key is to put SSRF back in its role as an "attack-surface amplifier":

• Which internal resources or endpoints you can reach (in a provable, reproducible, low-noise way)
• Why those endpoints are sensitive (management interfaces, internal APIs, points where sensitive information concentrates)
• Under a reasonable threat model, what the worst-case consequence could be (but avoid over-speculating; state your preconditions clearly)

Always read the scope before submitting a report: if the program explicitly states "SSRF with no impact is out of scope," then you need to build up your evidence before submitting, or you'll easily waste your time.

Closing Thoughts

SSRF's attack surface is broader than most people imagine, from URL previews to webhooks, from PDF generation to OAuth flows. Anywhere the server will "go fetch something" based on your input is worth testing.

For Bug Bounty hunters, the core methodology is:
Find a parameter carrying a full URL → confirm the outbound request with OOB → determine the reflection type → assess the blast radius with minimal cost and form a provable risk narrative. Push SSRF from "I can send a request" to "here's what it can actually cause," and the value of your report will go up.

For developers and security teams, defending against SSRF requires Defense in Depth: an application-layer scheme allowlist and post-resolution DNS validation are the foundation, while network-layer egress policy and segmentation are the safety net. Only by doing both together can you truly bring SSRF risk down.

Happy Hunting!