What is SSRF?

Server-Side Request Forgery, or SSRF, occurs when an application fetches a URL chosen or influenced by a user. The attacker uses the server as a proxy to reach internal services, cloud metadata endpoints or trusted partner systems that are not directly accessible from the internet.

Typical entry points are URL previews, webhook testers, image imports and PDF generators. In a blind SSRF the response is not returned directly, but timing, DNS lookups or callbacks can still prove that the server made the request.

How can SSRF be prevented?

• - Avoid arbitrary URLs and use an allowlist of required schemes, hosts and ports.
• - Resolve and validate every destination, including redirects, and block private, loopback and link-local ranges.
• - Restrict outbound traffic from application workloads at the network layer.
• - Protect cloud metadata services and do not attach unnecessary credentials to workloads.

Code example: choose a destination instead of accepting a URL

Vulnerable:

// The user controls scheme, host, port and path
$response = Http::get($request->input('url'));

Safer design for known integrations:

$providers = [
    'billing' => 'https://billing.example/api/status',
    'shipping' => 'https://shipping.example/api/status',
];

$provider = $request->string('provider')->toString();
abort_unless(array_key_exists($provider, $providers), 400);

$response = Http::timeout(3)
    ->withoutRedirecting()
    ->get($providers[$provider]);

Choosing from fixed destinations is more robust than filtering arbitrary URLs. If URLs must be flexible, use one canonical parser, validate DNS/IP on every connection and redirect, and enforce outbound firewall policy.

Why is URL validation difficult?

DNS can return different addresses over time, redirects change destinations and parsers disagree on unusual URL forms. A safe implementation validates the parsed and resolved target at connection time and combines application checks with network controls.

A typical SSRF attack path

The starting point is often a feature that imports images, verifies webhooks, renders PDFs or creates a URL preview. The attacker replaces the expected external address with an internal target. The server connects from its own network and with its own identity, potentially reaching services unavailable from the internet, such as management interfaces, internal APIs or cloud metadata endpoints.

Blind SSRF and possible impact

With blind SSRF, the application does not display the target's response. The request may still be observable through outbound DNS or HTTP traffic, timing differences or side effects. Depending on the environment, SSRF enables internal port scanning, credential retrieval, bypass of network-based controls or invocation of internal actions. A finding does not automatically prove data access; reachability and response handling need separate validation.

How is SSRF tested?

Testers identify every function in which the server retrieves a user-influenced resource. Controlled callback domains reveal outbound connections and DNS resolution. Redirects, alternative IP representations, IPv6, embedded credentials and differences between validation and retrieval are then examined. Internal production systems should only receive agreed, harmless requests during an authorized assessment.

Effective defence in depth

A narrow allowlist of destinations and protocols is the strongest application control. DNS results and every redirect must be checked again; private, loopback, link-local and metadata ranges should be blocked. A dedicated egress proxy can enforce and log destination policy. Cloud metadata services should require additional authentication. Network controls limit impact, while the application remains responsible for requesting only expected destinations.