SSRF Explained (2026): How to Find & Fix Server-Side Request Forgery

Server-Side Request Forgery (SSRF) happens when attackers can make your server fetch URLs they control, reaching internal services or cloud metadata. This guide shows common SSRF entry points, safe testing approaches, and real fixes like strict allowlists, redirect controls, and network egress filtering.

Tags: ssrf, server-side request forgery, owasp, cloud security, metadata service, web application security, input validation, network egress filtering, secure coding, vulnerability scanning

Server-Side Request Forgery (SSRF) is one of those vulnerabilities that looks harmless at first. The app fetches a URL, downloads an image, previews a link, calls a webhook, or pulls a file from a remote location. Then one day, that “fetch a URL” feature becomes a way for attackers to make your server talk to things it should never talk to, including internal admin panels, cloud metadata services, and private APIs.

This guide covers what SSRF is, why it matters in 2026 (especially in cloud and container-heavy environments), how to identify SSRF risk in your app, how to test safely on systems you own or have permission to assess, and how to fix it properly.

On this page

What is SSRF?

SSRF is a vulnerability where an attacker can influence a server-side application to make network requests that the attacker controls. Instead of the attacker’s browser sending a request directly, your server sends it on their behalf.

That distinction matters because your server often has:

In practical terms, SSRF turns your server into a network proxy for the attacker.

Why SSRF is dangerous

SSRF is not just “my app fetched the wrong URL.” It can be a stepping stone to serious outcomes, depending on what your server can reach.

1) Access to internal services

Many organisations have internal-only interfaces that are not designed to withstand hostile input because they are “not exposed to the internet.” SSRF bypasses that assumption by reaching those services from inside your network.

2) Cloud metadata access and credential theft

In cloud environments, SSRF is notorious for enabling access to instance metadata services. If an app server can reach metadata endpoints, attackers may retrieve sensitive identity data and then use it to access cloud resources.

3) Data exfiltration, probing, and pivoting

SSRF can be used to probe private IP ranges, map internal services, and sometimes exfiltrate data depending on how responses are handled. Even when responses are not returned to the attacker (often called “blind SSRF”), outbound requests can still leak information via timing, DNS, and request side effects.

4) The impact depends on your architecture

SSRF severity is heavily architecture-dependent. Two apps with the same bug can have wildly different real-world risk based on:

Common SSRF entry points

SSRF usually shows up anywhere your server fetches, previews, imports, or calls something based on user-controlled input.

How SSRF happens in real apps

Most SSRF is not caused by “obviously bad” code. It is caused by reasonable product features implemented without a strict request policy.

Typical patterns include:

SSRF can be:

Blind SSRF is still dangerous. If the server can reach something sensitive, the attacker might learn enough from timing, response codes, DNS callbacks, or downstream effects to exploit the access.

How to find SSRF in your code and features

If you are doing an audit, start with a simple question:

Where does the server make outbound network requests based on user-controlled input?

Code smells to search for

Feature review checklist

How to test SSRF safely

Only test SSRF on systems you own or have explicit permission to assess. SSRF testing can touch internal networks and cloud resources, so treat it like a potentially high-impact test.

What you are trying to prove

A practical, low-risk approach

  1. Start with a controlled endpoint you own and confirm whether your server performs the outbound request.
  2. Observe outbound request details in server logs or at your controlled endpoint (method, headers, user agent, source IP).
  3. Check redirect behaviour in a controlled way to see whether your server follows redirects.
  4. Test private network protections using a safe staging environment where internal addresses are intentionally mapped to non-sensitive services.
  5. Review egress controls (firewalls, NAT rules, service mesh policies) as part of the test, not after.

If you are doing this in a mature environment, the best SSRF “detector” is often:

How to fix SSRF properly

SSRF fixes fail when they are based on string checks alone. A robust fix combines input validation, destination restrictions, and network-level controls.

The golden rule: default deny

If your application must fetch remote content, the safest posture is:

Only allow outbound requests to a small, explicit set of destinations you trust.

In most products, “allow any URL” is a business convenience, not a security requirement. If you can redesign the feature so users select from known providers (for example, a short list of supported integrations), do that.

Allowlisting done right

A strong allowlist is based on the final resolved destination, not just the user-provided string.

Block internal address space

If you must support arbitrary hostnames (for example, “webhook endpoints”), enforce strong protections:

Also consider the “time of check vs time of use” problem: DNS answers can change. Strong implementations pin the resolved IP and connect to that IP directly, while still validating the hostname against policy.

Do not follow redirects by default

Redirects are a frequent SSRF bypass. If you allow redirects, you must re-validate the destination on every hop, and cap the number of redirects.

Harden the HTTP client

Use a dedicated fetcher service

For higher-risk features (like link previews), consider isolating outbound fetching into a separate service that has:

This turns SSRF from “server can reach everything” into “fetcher can reach only the public internet via a controlled path.”

Example policy (safe pseudocode)

The exact implementation depends on your language and infrastructure, but a good SSRF defence generally looks like this:

// Pseudocode outline
parse URL
require scheme in {https}
require port in {443}
require hostname matches allowlist policy
resolve hostname to IP(s)
for each IP:
  deny if IP is loopback, link-local, private, or otherwise restricted
connect with redirects disabled
enforce timeouts and max response size
return only what you actually need (often not the full body)

The goal is not “make the URL look safe.” The goal is “make it impossible for this code path to reach internal or sensitive destinations.”

Cloud and Kubernetes hardening

In 2026, many SSRF incidents become critical because the app workload has powerful cloud identity permissions or can reach sensitive cluster services.

Protect cloud metadata access

Even with good application validation, network-layer controls that prevent workloads from reaching metadata services are a major risk reducer.

Implement strong egress controls

Apply least-privilege IAM

If SSRF happens, the attacker inherits whatever the workload can access. Reduce blast radius by:

SSRF prevention checklist

Incident response if you suspect SSRF

If you suspect SSRF exploitation, treat it as a potential internal access event, not just a bug.

  1. Identify the entry point (feature, endpoint, parameter) and scope it across services.
  2. Review outbound logs for unusual destinations, bursts, and internal IP access attempts.
  3. Check for cloud identity abuse (unexpected calls to cloud APIs, new access keys, unusual object storage reads).
  4. Rotate exposed credentials and review secrets access.
  5. Lock down egress quickly if your architecture allows it (temporary deny rules can stop active exploitation).
  6. Patch with a defence-in-depth fix (validation plus network controls, not just one or the other).
  7. Hunt for follow-on activity (lateral movement, privilege escalation, persistence).

FAQ

Is SSRF the same as CSRF?

No. CSRF is about tricking a user’s browser into making an unwanted request. SSRF is about tricking a server into making a request. SSRF is often more dangerous because servers have privileged network access and identities.

Can a WAF stop SSRF?

A WAF might catch some obvious patterns, but SSRF is best solved inside the application and the network. Strong URL policies, destination allowlists, and egress controls are far more reliable than filtering strings at the edge.

Does SSRF always return data to the attacker?

No. Many SSRF cases are blind. The server makes the request, but the attacker does not see the response. Blind SSRF can still be exploited via outbound callbacks, timing, and side effects, and it can still enable access to internal services.

What features are most likely to introduce SSRF?

Anything that fetches a user-supplied URL: webhooks, link previews, “upload by URL”, remote image proxies, importers, and integrations that accept endpoints.

What is the best SSRF fix?

The best fix is a combination of:

Next steps

If you are building a broader web security program, these guides pair well with SSRF hardening:

If you want, I can write the next post in the same format: IDOR Vulnerabilities (2026): How to Detect and Fix Insecure Direct Object References.