Skip to content

Server-Side Request Forgery

Server-Side Request Forgery, or SSRF, occurs when an attacker tricks a server into making requests to unintended destinations.

Instead of directly reaching a target, the attacker abuses the vulnerable server as a request-making proxy.

Warning

Test SSRF only in authorized labs or approved assessment scopes. SSRF can affect internal systems that are not publicly exposed.

Overview

SSRF commonly appears when an application fetches a URL provided by the user.

Examples:

  • Stock check API URL
  • Webhook URL
  • PDF generation from URL
  • Image import from URL
  • Link preview feature
  • URL screenshot feature
  • XML or metadata fetcher
  • Server-side API integration

Example normal request:

POST /product/stock HTTP/1.1
Host: vulnerable.example
Content-Type: application/x-www-form-urlencoded

stockApi=http://stock.example.internal/product/stock/check?productId=6&storeId=1

If the user can control stockApi, they may point it somewhere unintended.

SSRF Against Localhost

The attacker can make the server request itself.

Payload examples:

http://localhost/admin
http://127.0.0.1/admin
http://127.0.0.1:8080/admin

Example:

POST /product/stock HTTP/1.1
Host: vulnerable.example
Content-Type: application/x-www-form-urlencoded

stockApi=http://localhost/admin

If /admin trusts local requests, the attacker may bypass normal external access controls.

Why Localhost SSRF Works

Local requests may be trusted because developers assume only the server itself can reach them.

Common reasons:

  • Admin panels bind only to localhost.
  • Reverse proxy handles external access control.
  • Internal ports are not exposed publicly.
  • Local services do not require authentication.
  • Debug interfaces are available internally.
  • Monitoring endpoints trust local traffic.

This makes SSRF useful for reaching services that are hidden from normal users.

SSRF Against Back-End Systems

Application servers often have access to internal networks that external users cannot reach.

Private IP ranges include:

Range Use
10.0.0.0/8 Private networks
172.16.0.0/12 Private networks
192.168.0.0/16 Private networks
127.0.0.0/8 Loopback
169.254.0.0/16 Link-local

Example internal payload:

http://192.168.0.68/admin

Example request:

POST /product/stock HTTP/1.1
Host: vulnerable.example
Content-Type: application/x-www-form-urlencoded

stockApi=http://192.168.0.68/admin

If the internal service trusts requests from the vulnerable server, the attacker may access it indirectly.

Cloud Metadata SSRF

In cloud environments, SSRF may expose instance metadata services.

Common metadata address:

http://169.254.169.254/

Possible impact:

  • Cloud credentials
  • IAM role tokens
  • Instance metadata
  • Internal configuration

Danger

Cloud metadata SSRF can be critical because temporary credentials may allow access to cloud resources.

Blind SSRF

Blind SSRF occurs when the application makes the request, but the response is not shown to the attacker.

In blind SSRF, detection may rely on out-of-band interaction.

Examples:

http://attacker-controlled-domain.example
http://collaborator-server.example

Signs of blind SSRF:

  • DNS lookup received
  • HTTP request received
  • Timing difference
  • Error message difference
  • Internal service behavior changes

Common SSRF Targets

Target Example
Localhost admin http://localhost/admin
Local port http://127.0.0.1:8080/
Internal subnet http://10.0.0.5/
Cloud metadata http://169.254.169.254/
Internal API http://api.internal.local/
Redis http://127.0.0.1:6379/
Elasticsearch http://127.0.0.1:9200/

Filter Bypasses

Applications may block obvious values like localhost or 127.0.0.1.

Potential bypass ideas in labs:

http://127.1/
http://0.0.0.0/
http://[::1]/
http://localhost./
http://127.0.0.1:80/

Alternative encodings or redirects may also bypass weak filters.

Note

SSRF filters are difficult to implement safely because URLs can be represented in many formats.

Impact

SSRF impact depends on what the server can reach.

Possible impact:

  • Access to internal admin panels
  • Internal network reconnaissance
  • Reading local services
  • Cloud metadata credential theft
  • Bypassing network-based access controls
  • Interacting with internal APIs
  • Pivoting through trusted server network access
  • Triggering requests to attacker-controlled systems

Testing Checklist

When testing for SSRF, look for features that fetch URLs.

Interesting parameters:

url=
uri=
path=
next=
redirect=
image=
stockApi=
callback=
webhook=
feed=
avatar=
document=

Testing steps:

  1. Identify a URL-fetching feature.
  2. Send a normal external URL.
  3. Confirm the server makes the request.
  4. Try localhost targets.
  5. Try internal IP ranges.
  6. Try non-standard ports.
  7. Try an out-of-band URL if response is blind.
  8. Check for filtering and bypasses.
  9. Confirm impact safely.

Remediation

SSRF prevention requires strict control over server-side requests.

Recommended defenses:

  • Avoid user-controlled URLs where possible.
  • Use an allowlist of approved hostnames.
  • Block loopback, private, link-local, and metadata IP ranges.
  • Resolve DNS and validate the final IP.
  • Revalidate after redirects.
  • Disable redirects unless needed.
  • Restrict allowed protocols to HTTP/HTTPS.
  • Do not allow arbitrary ports.
  • Use network egress filtering.
  • Require authentication on internal services.
  • Protect cloud metadata services.
  • Separate internal admin interfaces from application servers.

Safer Design

Instead of allowing arbitrary URLs:

Bad:
User provides full URL to fetch.

Better:
User selects from known supplier IDs.
Server maps supplier ID to approved backend URL.

Example:

supplier=warehouse-1

Server-side mapping:

warehouse-1 -> https://stock-api.internal/check

The user never controls the full URL.

Quick Reference

Attack Type Payload Example Goal
Localhost SSRF http://localhost/admin Access local admin interface
Loopback SSRF http://127.0.0.1:8080/ Reach local service
Internal SSRF http://192.168.0.68/admin Access internal systems
Cloud metadata http://169.254.169.254/ Read metadata/credentials
Blind SSRF http://attacker-controlled-domain Prove server-side request

Notes to Remember

  • SSRF makes the server send requests on the attacker's behalf.
  • Localhost from the server is different from localhost on the attacker's machine.
  • Internal services may trust requests from internal network locations.
  • Cloud metadata endpoints are high-value SSRF targets.
  • SSRF can be blind if the response is not returned.
  • Allowlisting is safer than blocklisting.
  • Egress filtering limits SSRF impact.