July 29, 2026

SSRF (Server-Side Request Forgery)

SSRF stands for Server-Side Request Forgery. It’s a vulnerability where an attacker gets a server to make a request it shouldn’t — to an…

By Anubhav_bora

4 min read

SSRF stands for Server-Side Request Forgery. It's a vulnerability where an attacker gets a server to make a request it shouldn't — to an internal system, a private IP, or somewhere else it was never meant to reach.

The key detail: the attacker isn't sending the request themselves. They're getting the server to do it, using the server's own network access and trust.

Why it's dangerous

Servers can usually reach things a normal visitor can't:

  • Internal admin panels with no public exposure
  • Private APIs and databases
  • Cloud metadata endpoints (which sometimes hand out credentials)
  • Other internal services sitting behind the firewall

If an attacker can steer a server-side request to a target of their choosing, they've basically turned the server into a proxy for attacking the internal network. Depending on what's back there, that can mean leaked credentials, unauthorized access to internal tools, or in bad cases, remote code execution.

A basic example

Say a shopping site checks stock levels by calling an internal API. The frontend passes in a URL, and the backend just fetches it:

stockApi=http://stock.example.com/check?productId=6

If the app doesn't validate that URL properly, an attacker can replace it:

stockApi=http://localhost/admin

The server now requests its own admin page — and hands the response back. A lot of apps quietly trust anything coming from localhost, on the assumption that only something already inside the system could make that request. SSRF breaks that assumption completely.

The same trick works against internal IPs like 192.168.0.68 — addresses the outside world can't touch directly, but the server can.

Why do apps trust "internal" traffic in the first place?

It's rarely a careless mistake — usually it's one of these:

  • Access control lives in a proxy or gateway in front of the app, so a request that reaches the app directly skips that check entirely.
  • There's a deliberate backdoor for account recovery, built on the assumption that only an admin could be on the local machine.
  • The admin panel runs on a separate port that's "not supposed to" be reachable from outside.

SSRF lets an attacker step into that trusted position from the outside.

How filters get bypassed

Most apps that know about SSRF try to filter it. Most of those filters have holes.

Blocklists (blocking 127.0.0.1, localhost, etc.) get bypassed with:

  • Alternate IP formats (decimal, octal, shorthand)
  • A domain you control that just resolves to 127.0.0.1
  • Case changes or URL-encoding to dodge simple string matches
  • A redirect that only kicks in after the filter has already approved the URL

Allowlists (only permitting specific domains) get bypassed by abusing how URLs are parsed:

  • Stuffing credentials before the real host: https://trusted-site:password@attacker-site
  • Hiding the real host after a # fragment
  • Registering a subdomain of the attacker's domain that contains the trusted name
  • Encoding or double-encoding characters so the filter and the actual request code disagree on what the URL means

There's also filter bypass via open redirect — if the trusted app has an unrelated open-redirect bug, an attacker can pass a URL that satisfies the allowlist, then let that page redirect the request straight to the real internal target.

Blind SSRF

Sometimes the server makes the forged request but never shows you the response. That's blind SSRF.

It's harder to get value out of, since you're not seeing what came back — but it's not useless. Attackers use it to:

  • Scan the internal network to map out what's reachable
  • Fire off exploit payloads at internal, unpatched systems
  • Get the server to connect to attacker-controlled infrastructure, which then responds with something malicious — occasionally leading to full RCE

Since there's no visible output, blind SSRF is usually confirmed with out-of-band techniques: send a request pointing to a domain you control, then watch for any incoming connection (even just a DNS lookup counts) as proof it fired.

Places SSRF hides that aren't obvious

  • Partial URLs — only a hostname or path fragment is user-controlled, and the rest gets assembled server-side.
  • XML and similar data formats — some parsers will fetch external URLs embedded in the document (this overlaps with XXE).
  • The Referer header — some analytics tools auto-visit whatever URL shows up there, which is exploitable if you control the header.

How to actually prevent SSRF

Filtering bad input helps, but as shown above, filters alone get bypassed constantly. Real prevention usually means layering several defenses so that even if one fails, the others hold.

Fix it at the network level (most reliable):

  • Segment your network so the app server can only reach what it actually needs. If it doesn't need to talk to internal admin panels or other services, it shouldn't be able to.
  • Firewall off internal services by default, and only whitelist specific connections the app genuinely requires.
  • Disable unnecessary network protocols on the server (SSRF often gets more dangerous when things like file://, gopher://, or dict:// are supported by the request library, not just [http://](http://).))..)

Fix it at the application level:

  • Use an allowlist for URLs, hostnames, or IPs — not a blocklist. Blocklists are always playing catch-up.
  • Validate the URL after full parsing, not with a naive string check. Parse it properly, resolve the hostname, and check the actual destination — not just the text the user typed.
  • Disable HTTP redirects in whatever library makes the outbound request, or at minimum re-validate the destination after every redirect hop. Don't validate once and then blindly follow wherever it leads.
  • If you only need certain input (like a product ID or store ID), don't accept a full URL from the user at all. Take the minimal piece of data you need and build the URL yourself server-side.
  • Avoid sending raw responses from internal requests back to the user. Even if SSRF exists, this limits it to "blind" SSRF, which is far less useful to an attacker.

Defense in depth:

  • Authenticate internal services properly instead of trusting requests just because they came from inside the network or from localhost. "It came from the local machine" should never be treated as proof of legitimacy.
  • Keep internal systems patched and hardened as if they were internet-facing. SSRF is often the first step in a chain — the second step is exploiting whatever weakness sits on that internal system.
  • Log and monitor outbound requests from your servers. Unusual destinations (internal IPs, cloud metadata endpoints, unfamiliar domains) are a strong signal something's wrong.

No single one of these is bulletproof on its own — allowlists have parsing edge cases, network segmentation can have gaps, and redirect validation can be implemented sloppily. The point is that combining them means an attacker has to beat multiple independent defenses at once, not just one clever bypass.