I Found SSRF in 30 Minutes: Here’s My Exact Bug Bounty Workflow (Complete Guide) | by Samadhan…

Server-Side Request Forgery (SSRF) is a web security vulnerability that occurs when an application makes a server-side request using input that an attacker can influence.

The problem is that the server may have access to resources that an external user cannot reach directly. If the application does not validate these requests properly, an attacker may be able to make the server contact unintended systems.

In some cases, SSRF can expose internal services, sensitive information, or cloud infrastructure. However, the actual impact depends on the application's configuration, network permissions, and security controls.

In this guide, we will explore how to identify potential SSRF entry points, confirm the vulnerability, understand common defenses, and assess its real impact during authorized security testing.

1. What Is SSRF?

Imagine a website that allows users to enter an image URL. The server downloads the image and displays it on the website.

For example, a user submits a URL, and the application sends a request to retrieve the image. If the application accepts arbitrary URLs without proper validation, the feature could become an SSRF entry point.

The important detail is that the request comes from the server, not directly from the user's browser. This can give the request access to network locations that the user cannot reach.

SSRF is not limited to image processing. It can also appear in PDF generators, webhook integrations, URL preview features, document converters, and other functions that retrieve remote resources.

2. Where Should You Look for SSRF?

Before testing payloads, understand how the application works. The goal is to find features that might cause the server to contact another URL or service.

URL Parameters

Start by reviewing parameters that appear to accept URLs or destinations.

Common examples include:

• url
• uri
• target
• dest
• redirect
• callback
• webhook
• returnTo

These names are only clues. A parameter called url is not automatically vulnerable, and SSRF can exist in parameters with completely different names.

API Endpoints

Review API routes that appear to fetch, process, or forward external resources.

For example, endpoints responsible for URL previews, remote image imports, webhook testing, and document generation may make server-side requests.

Read the application's normal responses and observe how the feature behaves. Understanding its intended function helps you identify unusual request patterns.

File Processing Features

File-processing features are worth investigating because they may retrieve remote content before producing an output.

Examples include PDF generation, image resizing, website screenshots, and document conversion.

A useful question is: does the application process only files uploaded by the user, or can it also download resources from a URL?

Integrations and Webhooks

Applications often connect to external services through webhooks, RSS readers, API integrations, and monitoring tools.

A webhook configuration page, for example, may allow a user to enter a destination URL that the server later contacts.

Check whether the application validates destinations, restricts access to sensitive network ranges, and applies appropriate controls to outgoing requests.

HTTP Headers and Other Inputs

Some applications use HTTP headers or structured input to determine where requests should be sent.

Headers such as Referer, Origin, Host, and forwarded-host headers deserve attention when the application's behavior suggests that they influence server-side fetching.

XML parsers can also create related risks through XML External Entity (XXE) vulnerabilities. Media-processing systems and URL-based authentication workflows may introduce additional request paths.

The key is to follow the application's data flow rather than blindly testing every possible parameter.

3. How to Confirm a Potential SSRF

Finding a suspicious parameter is only the first step. You must establish that the server actually makes a request based on your input.

For reliable results, use a controlled environment, an application you own, or a bug bounty target where the testing activity is explicitly permitted.

In-Band SSRF

In-band SSRF occurs when the application returns some of the fetched resource's response to the user.

For example, an application might accept a URL and display the retrieved page content. If a controlled test URL produces content that matches the resource you configured, that may indicate server-side fetching.

However, make sure the request is not coming from your browser. Browser developer tools, server-side logs, and controlled test endpoints can help distinguish the two.

Blind SSRF

Blind SSRF occurs when the application makes a server-side request, but the response is not displayed to the user.

This can make the vulnerability harder to detect because the application's response may look completely normal.

An Out-of-Band Application Security Testing (OAST) service can help confirm whether an external interaction occurred.

For example, you can use a unique callback URL from an approved testing service and submit it through a suspected URL-fetching feature. If the service records a corresponding DNS lookup or HTTP request, investigate whether the interaction originated from the target application.

A callback alone does not prove that every form of SSRF is exploitable. Confirm the relationship between the application action and the callback, account for automated security scanners, and evaluate what the server was able to access.

Useful OAST Tools

Burp Collaborator: Integrated with Burp Suite Professional, it helps detect external DNS and HTTP interactions during manual testing.

Interactsh: An open-source OAST tool from ProjectDiscovery that supports detecting out-of-band interactions.

Both can be useful for identifying blind behavior, but the evidence must be interpreted carefully. DNS-only interactions, for example, do not necessarily prove that an HTTP request succeeded.

4. Understanding SSRF Filters and Bypasses

Many applications try to prevent SSRF by blocking internal IP addresses, allowing only trusted domains, or restricting supported URL schemes.

These controls can fail when validation is incomplete or when the URL validator and the HTTP client interpret the same input differently.

IP Address Validation

A weak filter might check only a few familiar IP address strings instead of determining the actual destination address.

IP addresses can have alternative representations, and IPv6 introduces additional parsing considerations. A secure implementation should validate the parsed address and its resolved destination rather than rely on simple string matching.

For authorized testing, focus on whether the application correctly rejects destinations that fall outside its documented allowlist.

URL Parsing Differences

URLs can be interpreted differently by different libraries. User information, unusual delimiters, redirects, and differences between URL parsers can create unexpected behavior.

For example, a URL containing an @ symbol may identify one host as user information and another as the actual destination. A superficial string check can therefore be misleading.

The defense is to use a consistent URL parser, validate the parsed hostname, and ensure that the actual connection goes to the approved destination.

Redirect Handling

A server may validate an initial URL and then follow a redirect to a different destination.

If the application checks only the first URL, a redirect can undermine the intended restriction.

Applications that fetch remote resources should validate redirect destinations as well as the initial URL. Where redirects are unnecessary, disabling them can simplify the security controls.

DNS Rebinding

DNS rebinding is a more advanced issue involving changes in DNS resolution.

An application might validate a hostname when it resolves to a public address, then make a later request after the hostname resolves to a different address.

Defending against this requires more than validating the hostname once. Applications should validate resolved addresses, control redirects, and enforce network restrictions at the connection layer.

5. What Is the Real Impact of SSRF?

Not every SSRF vulnerability has the same severity. A server fetching an arbitrary public webpage may present a different level of risk from a server that can reach sensitive internal services.

The impact depends on what the application can access, what information it returns, and whether additional security controls are in place.

Internal Services

A vulnerable application may be able to reach internal APIs, administration panels, or services that are not exposed to the public internet.

If these services trust requests from internal network locations, SSRF may create a path around an intended security boundary.

During an authorized assessment, use safe evidence to establish whether the destination is reachable. Do not attempt to access unrelated systems or perform intrusive network-wide probing.

Cloud Metadata Services

Cloud environments may provide instance metadata services that expose information about the virtual machine and its configuration.

Some metadata endpoints can also provide temporary credentials, depending on the cloud provider and the instance's permissions.

For example, AWS, Google Cloud, and Microsoft Azure offer metadata services with different endpoint structures and security requirements. AWS IMDSv2 requires a session token obtained through a separate request, which can mitigate some SSRF attack paths.

For bug bounty testing, never retrieve or disclose real cloud credentials. Use program-approved, non-sensitive evidence to demonstrate the security boundary and explain the potential impact.

Local File and Alternative Protocol Access

Some server-side libraries support schemes beyond HTTP and HTTPS. Depending on the library and its configuration, unsupported assumptions about URL schemes can introduce additional risks.

For example, file-access schemes and protocols intended for other network services may behave differently from ordinary web requests.

Do not assume that every SSRF vulnerability supports these schemes. The available behavior depends on the actual library, runtime, and application configuration.

The safest approach is to document supported schemes and validate them in an isolated test environment instead of attempting to interact with sensitive production resources.

6. Tools That Can Help With SSRF Testing

The following tools can help with different stages of an authorized assessment.

Burp Suite: Useful for intercepting HTTP requests, modifying inputs, comparing responses, and examining application behavior.

Burp Collaborator: Helps identify blind interactions when an application contacts an external testing endpoint.

Interactsh: Provides out-of-band interaction monitoring and can be useful in automated testing workflows.

Collaborator Everywhere: A Burp Suite extension designed to help identify potential out-of-band interactions by testing request inputs and headers.

Gopherus: A research tool associated with generating protocol-specific payloads. Its applicability depends on the server-side client and supported protocols; it is not required for ordinary SSRF detection.

SSRF Proxy and CloudCrawler: Names used for tools or projects associated with SSRF research and cloud-related testing. Verify the specific project's source, maintenance status, and capabilities before relying on it.

Tools can reduce manual effort, but they cannot replace understanding the application's intended behavior. A scanner finding should always be validated before it becomes a security report.

7. How to Write a Good SSRF Bug Bounty Report

A good report explains what the application does, why the behavior is unexpected, and what security boundary is affected.

Avoid making claims about credential theft, remote code execution, or internal network access unless you have evidence to support them.

A practical report can use the following structure.

Title: Server-Side Request Forgery in the URL Preview Feature

Summary: The URL preview feature appears to make server-side requests to user-supplied destinations without adequately restricting the destination.

Affected endpoint: Include the exact endpoint and the relevant parameter, while avoiding sensitive information.

Steps to reproduce:

1. Access the feature using an authorized test account.
2. Submit a URL pointing to a controlled testing endpoint.
3. Monitor the endpoint for DNS or HTTP interactions.
4. Repeat the test where necessary to rule out unrelated traffic.
5. Record the request, response, and callback evidence.

Observed result: Describe exactly what the application did and what evidence confirmed the server-side interaction.

Expected result: The application should restrict outgoing requests to approved destinations and prevent access to sensitive internal resources.

Impact: Explain the realistic consequences based on the demonstrated access. If internal resources or sensitive data were not accessed, state that the potential impact has not yet been confirmed.

Suggested remediation: Apply strict destination allowlists, validate resolved IP addresses, restrict redirect behavior, allow only necessary URL schemes, and enforce outbound network controls.

Severity: Choose the severity based on the demonstrated impact, the application's exposure, and the bug bounty program's rating criteria. SSRF is not automatically a High or Critical vulnerability.

8. How Developers Can Prevent SSRF

The strongest defenses work together rather than depending on a single filter.

Use an allowlist. Where possible, allow requests only to explicitly approved domains and destinations.

Validate destinations carefully. Parse URLs with a reliable library, restrict schemes to those required, and validate DNS resolutions and IP addresses.

Control redirects. Validate each redirect destination or disable redirects when they are not needed.

Restrict network access. Prevent application servers from reaching sensitive internal services and metadata endpoints unless that access is explicitly required.

Apply least privilege. Limit the permissions of cloud identities and service accounts so that a successful SSRF cannot automatically expose powerful credentials.

Monitor outgoing requests. Logging and alerting can help identify unusual destinations, unexpected protocols, and repeated attempts to access restricted resources.

These controls are most effective when implemented at multiple layers, including the application, HTTP client, and network.

Conclusion

SSRF is an important vulnerability for bug bounty hunters because it can expose security boundaries that are not visible from the browser alone.

The best way to find it is to understand where the application makes outgoing requests, identify user-controlled inputs, and verify the behavior using controlled testing endpoints.

Remember that a suspicious parameter is not proof of SSRF, and a confirmed callback does not automatically mean that sensitive internal resources are accessible.

Focus on reproducible evidence, realistic impact, and clear reporting. Responsible testing and accurate conclusions are what turn a potential finding into a useful security report.

AI assistance:_ I used an AI-powered grammar and spelling checker to review this article. The ideas, research, technical analysis, and final content are my own._

Have questions or want to share your own workflow? Drop a comment below or connect with me on :

🔗Linkdin: https://www.linkedin.com/company/sam-shield/

🔗Youtube: https://www.youtube.com/@sam_shield-w7l

🔗Medium: https://medium.com/@samadhanshimple