SSRF Explained for Developers and Pentesters

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can influence a server-side application to send a request to an unintended destination.

This matters because the server often has network access that the attacker does not have. It may reach internal services, cloud infrastructure, private APIs, admin panels, or trusted network zones. The attacker does not directly connect to those systems. The vulnerable application connects on their behalf.

The core idea is simple:

SSRF happens when untrusted input controls where the server sends a request.

Image: Type: Context. Mô tả: “A diagram showing an attacker controlling a URL parameter, the web server making the request, and the target being an internal or external service.” caption: “In SSRF, the vulnerable server becomes the request origin.”

Context

Modern applications frequently fetch remote resources:

  • Importing an image from a URL
  • Generating a preview from a link
  • Calling a webhook
  • Fetching metadata from an integration
  • Downloading a document from cloud storage
  • Validating an external callback URL
  • Proxying a request through a backend service

Example feature:

POST /api/preview HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "url": "https://example-cdn.com/image.png"
}

Expected behavior: the server fetches the image and generates a preview.

Vulnerable behavior: the user-controlled url can point somewhere the application should never access.

Root Cause

SSRF usually appears because developers focus on functionality:

“The user gives us a URL, then our server fetches it.”

The missing security question is:

“Which destinations is this server allowed to reach?”

Common root causes include:

  • User-controlled URLs are fetched without strict validation.
  • The application only checks the URL format, not the resolved destination.
  • The application allows redirects to untrusted destinations.
  • The backend has broad network access.
  • Internal services trust requests from the application server.
  • Cloud or infrastructure metadata services are reachable from the application runtime.
  • The application has no egress filtering.

SSRF is not only an input validation issue. It is also a network trust and architecture issue.

Impact

SSRF impact depends on what the vulnerable server can reach.

Possible impact includes:

  • Internal service discovery
  • Access to internal-only admin panels
  • Reading internal API responses
  • Reaching cloud metadata services
  • Leaking credentials or tokens
  • Triggering actions on internal systems
  • Bypassing network controls
  • Pivoting into deeper application logic

Some SSRF findings are low impact if the server can only fetch public resources and responses are not returned. Other SSRF findings become critical when the server can access sensitive internal services or secrets.

Image: Type: Test case. Mô tả: “A lab environment showing an SSRF request in Burp Suite Repeater and a controlled internal test service responding. Use PortSwigger SSRF labs or a private test service.” caption: “SSRF testing should use controlled lab targets, not unauthorized internal systems.”

Signature

Look for endpoints that accept URLs, domains, webhooks, callbacks, or remote resource references.

Interesting parameter names include:

  • url
  • uri
  • link
  • target
  • endpoint
  • callback
  • webhook
  • redirect_uri
  • avatar_url
  • image_url
  • feed
  • next

Interesting features include:

  • Link preview generators
  • PDF generators
  • Image importers
  • Webhook configuration pages
  • OAuth or SSO callback settings
  • Integrations with Slack, Jira, GitHub, or cloud services
  • Server-side proxy endpoints
  • XML parsers that fetch external resources

Response clues may include:

  • The application returns the fetched content.
  • The response time changes based on the destination.
  • Error messages reveal DNS, connection, or HTTP client behavior.
  • The application follows redirects.
  • A collaborator-style server receives a request from the target backend.

How to Test Safely

Only test SSRF in authorized scopes or labs. Good safe options include PortSwigger Web Security Academy, private test services, and approved internal lab environments.

A safe workflow:

  1. Identify features that accept a URL or remote endpoint.
  2. Use a domain you control or a collaborator endpoint to confirm whether the server makes an outbound request.
  3. Observe source IP, headers, HTTP method, and timing.
  4. Test whether redirects are followed in a controlled way.
  5. Avoid probing real internal networks unless the rules of engagement explicitly allow it.
  6. Document the request flow and explain what the server can reach.

The goal is not to scan internal networks through the server. The goal is to prove that destination control is not constrained.

Image: Type: PoC. Mô tả: “A safe collaborator-style callback showing that the target server made an outbound HTTP request to a controlled domain. Blur target identifiers if needed.” caption: “A controlled callback is usually enough to prove server-side request behavior.”

Common Variants

1. Basic SSRF

The application fetches a URL supplied by the user and returns the response.

This is the easiest variant to identify because the response body may reveal what the server fetched.

2. Blind SSRF

The application makes the request, but the response is not returned to the user.

This is common in webhook validation, PDF generation, analytics, and asynchronous job systems. Detection often requires a controlled external endpoint.

3. SSRF via Redirect

The application validates the first URL but follows a redirect to a different destination.

Developers often forget that validation must apply to the final destination after redirects, not only the initial input.

4. SSRF Through File or Media Processing

Some libraries fetch external resources while processing HTML, XML, images, or documents. The vulnerable input may not look like a URL parameter at first.

Remediation

Strong SSRF prevention combines application controls and network controls.

Application-level defenses:

  • Use allowlists for approved destination domains.
  • Avoid arbitrary URL fetching when possible.
  • Validate scheme, host, port, and resolved IP.
  • Re-validate after redirects.
  • Block access to private, loopback, link-local, and internal address ranges when not explicitly required.
  • Do not return raw internal responses to users.
  • Set strict timeouts and response size limits.
  • Use dedicated fetcher services with narrow permissions.

Network-level defenses:

  • Apply egress filtering.
  • Restrict backend access to internal services.
  • Segment sensitive infrastructure.
  • Require authentication between internal services.
  • Harden cloud metadata access where applicable.
  • Monitor unusual outbound traffic from application servers.

A mature defense assumes input validation may fail and limits what the server can reach anyway.

Developer Mental Model

Do not treat SSRF as merely “bad URL validation.” Treat it as untrusted routing control.

A safer design is:

User selects an approved integration -> server maps it to a trusted endpoint -> outbound request is made with strict egress policy

An unsafe design is:

User submits any URL -> server fetches it from a privileged network position

That difference is the heart of SSRF prevention.

References

CTA

KevinSec can help review URL-fetching features, webhook integrations, PDF generators, and backend service trust boundaries. If your application accepts external URLs, it deserves a focused SSRF review before production exposure.